[00:27] how do i merge lp:~quickshotdevs/quickshot/luke-quickshot into lp:quickshot? [00:35] ubuntujenkins: pull the lp:quickshot branch, go into that directory, then br merge lp:~quickshotdevs/quickshot/luke-quickshot [00:35] cool thanks === elpargo_ is now known as elpargo === Kilroo1 is now known as Kilroo [08:00] Hi, I want to have a subdirectory of a repository to have seperate defaults to the rest, is it safe to just initialise another in there or is there another way I should approach it? [08:04] Oh hmmm, I probably should just avoid adding that directory ey? [12:24] Hi all [12:25] can anyoune tell me what's the command to view a screen like this: http://samba.org/~jelmer/bzr/bzrk.png [12:25] en1gm4: bzr viz [12:25] it's part of the bzr-gtk plugin [12:25] jelmer: thanks a lot! [12:26] yes I installed it but thought its command start with g*** [12:26] ok it works thanks! [16:28] maxb: hi [18:53] ok, i've probably asked this before, but i tend to forget things a lot [18:53] but when you move files, doesn't Bzr only log a move? [18:53] actually, i'm sure i've asked that before, but don't remember the answer === radoe_ is now known as radoe [19:25] meoblast001: kind of, it just reflects the changed locations of things in the inventory [19:26] ok, so it doesn't log as file deleted, new file created? [19:26] just a move [19:28] ah, ok, goo [19:28] d [19:29] i dont think there is a vcs that records a delete+new (all that im aware of is recording copy+delete) [19:44] ronny_: CVS? :) [19:45] luks: is cvs really a vcs? [19:46] certainly [19:46] well, it has it even in it's name [19:46] ronny_: git [19:46] ronny_: (doesn't record copies, so it does delete + new) [19:46] lifeless: git doesnt record deletes either, it just records tree state [19:47] ronny_: well, from that angle so does bzr [19:48] lifeless: bzr cares about item histories and where a item is uniequely placed [19:48] git is just a state of trees of blob [19:48] ronny_: its tooearly for this. I assure you though, bzr does not record deltas. [19:49] any more than git does; bzr is snapshot focused. [19:49] lifeless: i didnt mention deltas, afair all of the major 'good' vcs's see them as internal optimazion [19:50] jelmer: I'm coming from LP #533407, do you have instructions on how to use the trunk versions of dulwich and git ? [19:50] Launchpad bug 533407 in bzr-git "bzr-git craches on pull in shamap.py , add_entry()" [Undecided,New] https://launchpad.net/bugs/533407 [19:50] well you claim 'git doesn't record deletes' - a delete is part of a delta [19:50] you can't have a debate about 'storing deletes' - or not - without the concept of a delta being present. [19:50] jelmer: I grabbed the trunks of both, but how do I set them up ? [19:50] darcs doesn't count as good anymore? [19:51] luks: darcs isnt major [19:51] I wants: http://web.media.mit.edu/~marcelo/cornucopia/ [19:52] heh [19:52] lifeless: everyone that saw star-trek does [19:52] :) [19:53] hmm, i think git is the most snapshot oriented, bzr carries way too much metadata about inventories [19:56] only the file ID [19:56] the rest is the same [19:56] but the file ID makes a big difference [19:56] where? [19:57] the difference? in how you can view the system [19:58] the only thing it really can help is annotate on a single file history [19:58] oh, I didn't mean functional differences [19:59] my usual view is tree of files' how do file-id's add a new perspective? [20:01] they don't (most filesystems represent files as ids anyway), git's no-file-ids add a new perspective [20:02] so where do they make the difference in viewing the system [20:02] in the definition of a snapshot [20:03] you said that git is the most snapshot oriented system [20:03] but the only difference is that bzr keeps file ids [20:03] so there is a difference in what people consider to be snapshots [20:04] bzr has a lot of metadata that relates items within one snapshot to the previous snapshot [20:05] no [20:05] what kind of metadata? [20:05] relates items in one snapshot to any other snapshot <- I'll accept that statement [20:05] luks: file id, content-revision-id [20:06] lifeless: my sloppy wording again :( [20:06] oh right, I forgot about per-file revisions [20:06] ronny_: :P de nada [20:15] lifeless: i decided to degrade bzr from fully wanted to 'pass the tests' in anyvc [20:34] ronny_: oh, thats a shame [20:55] lifeless: since having bzr in my mind actively complicated some of my mindmodels more than ever should be necessary i lost all reasons not to === elpargo_ is now known as elpargo [22:14] anyone from japan here? Or know japanese immigrants who've lived in the USA whom I can ask a few questions? [22:55] jelmer: "merge dave" isn't much of a commit message :-) [22:56] mwhudson: but makes a great potential title for a romantic comedy (or porn film) [23:07] * jelmer tries to be smart and keeps quiet === Kilroo1 is now known as Kilroo [23:41] is there any command for undoing a given diff? [23:42] kinda out of scope [23:42] patch -R [23:43] bzr: ERROR: no such option: -R [23:43] nothing to do with bzr [23:43] the gnu patch tool can apply diffs backwards [23:43] can you get what I want? [23:43] e.g. you are in rev 100 [23:43] then you realize that rev 80 was a mistake, then you want to undo it [23:44] bzr merge -r 80..79 [23:44] it would be nice to have something like bzr revert -r 80 [23:44] or... [23:44] idnar: nice, will try it [23:44] hmm [23:44] doesn't look like there's an easier way to specify it [23:45] -c 80 will get you 79..80 [23:45] -c -80? [23:46] bzr merge -r 80..79 doesn't work, it generates a conflict in a file, non-sense, the file wasn't edited in that revision [23:46] bet you it was [23:46] bob2: -80 will get you the revision 80 revisions before HEAD, I think [23:46] ah [23:47] RenatoSilva: are you sure r80 is the one you want to revert? [23:47] of course [23:47] it's actually 146, but that doesn't matter [23:47] so you're using -r 146..145? [23:47] 146 should not exist, so bzr merge -r 146..145 [23:47] yes [23:48] You need the dot. "bzr merge -r80..79 ." [23:48] oh [23:48] oh, that's my bad [23:48] That won't make it not exist. It just reverses the change and sets you up to commit that. [23:48] of course [23:48] There's no way to make it not exist without rewriting all the revs after. [23:48] no one said it would [23:48] Well, re " 146 should not exist [...]" [23:49] fullermd: and? [23:49] Just sayin'. [23:49] no, I didn't say [23:49] oh, I think RenatoSilva meant "146 is the rev I'd like to undo the effect of"? [23:49] should != will [23:50] I know. I'm just clarifying. [23:50] bob2: should not exist == if I could go back in time, I would not commit it [23:51] which may be possible if I find The Island [23:51] fullermd: ok [23:52] bzr merge -r 146..145 . is sort of workaround right? it generates a conflict for the change, it doesn't actually patch the file [23:53] hmm, it doesn't work either [23:53] it's not a workaround, it is asking bzr to undo that change [23:53] if I simply accept the merge source, I could be reverting valid changes in further commits (my case here) [23:54] <<<<<<< TREE [23:54] div.header, div.footer, div.sidebar, ul#timings, div#interwiki, table.navigation, a.action { [23:54] ======= [23:54] div.header, div.footer, div.sidebar, div#interwiki { [23:54] >>>>>>> MERGE-SOURCE [23:54] it should be: [23:54] div.header, div.footer, div.sidebar, div#interwiki, ul#timings, { [23:54] >>>>>>> MERGE-SOURCE [23:54] is this repo available? [23:55] hmm that's right [23:55] if a further rev did not chnage that line, the conflict would not happen I think [23:55] if there have been other changes since r146 that conflict with undoing r146, then I would expect to see conflicts [23:55] which you'll then have to manually resolve [23:55] it's really a conflict I must solve [23:57] so ok, my bad, but I don't get bzr merge -r 146..145 ., although I know the pratical result. I would get better bzr revert -r 146..145 [23:57] anyway, this is not so useful, it's more easy to just see the changes and undo them manually [23:58] but thanks all anyway [23:59] is there how to bzr diff -r 146..? [23:59] bzr diff -r 146 [23:59] ok thanks!