[00:02] hello! Im seeking help! [00:02] frikazoyd: oh hai [00:02] beat you to it [00:02] :P [00:04] MapMan: just ask [00:04] Verterok: my mate frikazoyd already asked [00:04] ok, then [00:06] maybe you can help us though [00:06] we have a problem with bzr [00:06] every commit > push causes a lock [00:06] and everytime someone wants to push, he needs to break lock [00:11] well, I know where my disk space has gone [00:11] evo -> 6.4g used [00:11] !!! [00:12] frikazoyd: the branch you are pushing to; is it on nfs/ftp/sftp/bzr+ssh ? [00:12] frikazoyd: and are the permissions set to allow both of you to create and delete common files? [00:13] its ftp mate [00:13] i dunno about the permissions, i havnt seen the cfg [00:13] check in ~/.bzr.log for errors related to deleting [00:13] (unless break-lock does work, in which case you clearly can delete) [00:14] might be a ftp server bug that you can't delete a file you created in the same session or something weird [00:14] anyhow, its not usual, we do work on ftp; please file a bug and the devs can ask for details there to figure out whats wrong (if you can't figure out a config issue shortly) [00:16] hi everyone [00:17] I get this error trying to push: http://paste.pocoo.org/show/86007/ [00:17] now I try what it suggested but unknown protocol [00:17] is it a launhcpad thing or a bzr thing? [00:20] aa_: it's a bit of both [00:20] aa_: use bzr break-lock with your usual URL. [00:20] aa_: e.g. bzr break-lock lp:~name/proj/foo [00:22] Lifeless: The problem isn't that we can't delete, the problem is that a lock is automatically created if someone pushes [00:22] and it doesn't release [00:22] so if I commit a file in a local branch and then push, it puts a lock on the central repo I'm pushing to [00:23] so nobody else can push that file either (even if it is up to date before editing) unless they break my lock [00:23] We don't want to have to break locks to commit and merge every time someone changes an existing file [00:24] frikazoyd: I'm talking about the technical details required to manage the transient locks bzr uses to ensure data consistency as it pushes [00:24] frikazoyd: please assume I understand exactly what you want and how it works and am trying to help you get it to work as it *should* for you. [00:25] Oh [00:25] the .bzr.log file doesn't exist [00:26] also breaking works fine [00:26] bzr --version [00:26] will have a line like [00:26] Bazaar log file: /home/robertc/.bzr.log [00:26] with the full path to the local log file [00:26] we use windows binaries [00:26] Okay [00:26] Map: You can do it from command line :P [00:26] its in default user folder in windows [00:27] I hate that, it should be placed in apps folder [00:27] spiv: I did that and it returns without error, but it doesn't break the lock [00:28] spiv: doesn't break the lock == still has the cannot get lock error [00:30] aa_: its https://bugs.edge.launchpad.net/bzr/+bug/255062, btw [00:30] Ubuntu bug 255062 in bzr "bzr: ERROR: Invalid url supplied to transport: "Host empty in" [High,Confirmed] [00:31] aa_: That should break the lock. You could try "bzr break-lock sftp://aafshar@bazaar.launchpad.net/~glashammer-devs/glashammer/glashammer-main" instead, but that shouldn't be any different. [00:31] aa_: Hmm, by "returns without error", you mean it doesn't output anything, not even a prompt? [00:32] spiv: no just returns [00:32] I get the shell prompt afterwards [00:32] and return code is 0 [00:33] Ok, then there is no lock to break. [00:33] "locked 24 minutes, 59 seconds ago" [00:33] What's cannot get lock error look like? [00:33] spiv: that thing I apsted [00:33] (and on what operation?) [00:33] on bzr push [00:34] its exactly the thing I pasted here http://paste.pocoo.org/show/86007/ except the time is creeping up === Guest25912 is now known as jelmer [00:36] Is your launchpad user a member of glashammer-devs? [00:36] yes [00:36] Hmm, it appears it is. [00:37] What URL exactly is your local branch pushing to? [00:37] spiv: if I forget about it for a while is it likely to go away, or will it stay forever? [00:38] It isn't going to go away by itself unless the connection that created it is still connected. [00:38] bzr push bzr+ssh://aafshar@bazaar.launchpad.net/%7Eglashammer-devs/glashammer/glashammer-main/ [00:39] locked 30 minutes, 44 seconds ago? [y/n]: [00:39] that's new [00:39] yay [00:39] spiv: guess I was running break-lock on the wrong url [00:40] spiv: sorry for the bother [00:40] That's ok. [00:40] Glad to hear that you're sorted. [02:11] poolie: Did you get my email with bank details? I never got an ACK. [02:13] Odd_Bloke: hi, yes, i passed it on to our finance guy [02:13] poolie: Cool, thanks. :) [02:13] i wonder if gpg defeated him because i didn't hear anything myself :) [02:13] Heh. [02:13] but i did send an extra comment explaining it [02:15] morning all [02:16] hello igc, how are you going? [02:16] hi poolie - ok today [02:20] igc: Hey, long time no see. [02:20] hi Odd_Bloke! === sdboyer|oot is now known as sdboyer [02:54] jam, the description of the change to log seems to make sense to me too [02:54] if you want me to look at it harder, just say so === spiv_ is now known as spiv [03:31] i'm trying to work out what's up with the oldest queued patch, "setlocale (bug 128496)" [03:31] Launchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Fix released] https://launchpad.net/bugs/128496 [03:37] is it correct that opening a RemoteBranch always opens the underlying disk branch ? [03:40] yes [03:41] k, I'll do an isinstance in my branch hook open tests [03:41] hrm, ok [03:42] lifeless: it's a bit hard to avoid it given the repository stacking must be configured when the branch is opened [03:42] poolie: yeah [03:42] poolie: its just to make the interface tests that say what the hook should do, pass [03:43] obviously you could just make a promise to do it later, but iirc people have argued errors with the repo must be detected then [03:43] If spiv knows that opening a remote branch generates remote + normal object [03:43] I'm aware that the stacking stuff has caused that, yeah :( [03:43] elf.assertEqual([b], self.hook_calls) [03:43] AssertionError: not equal: [03:43] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:43] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:43] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:43] AssertionError: not equal: [03:43] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:43] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:43] BzrBranch6('chroot-46912499497232:///')] [03:43] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:43] AssertionError: not equal: [03:43] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:43] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:43] BzrBranch6('chroot-46912499497232:///')] [03:43] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:43] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] BzrBranch6('chroot-46912499497232:///')] [03:44] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:44] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] BzrBranch6('chroot-46912499497232:///')] [03:44] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:44] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] BzrBranch6('chroot-46912499497232:///')] [03:44] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:44] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] BzrBranch6('chroot-46912499497232:///')] [03:44] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:44] lifeless: oops [03:44] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] BzrBranch6('chroot-46912499497232:///')] [03:44] BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls) [03:44] AssertionError: not equal: [03:44] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:44] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:44] oooooh [03:44] sorry [03:45] no idea what caused that; wifi glitch I guess [03:45] (it wasn't pasting, so I tried again..) [03:45] lifeless: stop playing hopscotch on your middle mouse button ;) [03:45] spiv: anyhow [03:45] self.assertEqual([b], self.hook_calls) [03:45] AssertionError: not equal: [03:45] a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)] [03:45] b = [RemoteBranch(bzr://127.0.0.1:49396/extra/), [03:45] BzrBranch6('chroot-46912499497232:///')] [03:45] thats the clear unmixed up assertion [03:45] so I propose to isinstance it and changed the expect value appropriately. [03:48] that sound ok? [03:51] (sorry, lag on my end isn't helping) [03:53] adjusting the test for the RemoteBranch scenario to assert that the hook observes the same remote branch get opened, plus a non-RemoteBranch, sounds good to me. [03:53] Given that's what (currently) happens. [03:53] well specifically, I'll use the real branch from the opened branch [03:53] Ah, ok. [03:54] we know what it is after all, no need for a hand-wave [03:54] Yeah, that makes sense. "if isinstance(b, RemoteBranch): expected.append(b._real_branch)", basically? [03:54] yes [03:54] Sounds reasonable. [03:54] is that bb:approve to this change ? [03:58] Sure. [03:58] thanks [04:03] oh, I see, it is a remote VFS call already [04:03] tweaking more [04:03] can I ask though, why the current find_branch wasn't just extended to return the stacking url as well, to avoid additional round trips ? [04:06] spiv: here? [04:09] lifeless: intermittently, it seems. [04:09] "Lag: 51 (??)" [04:10] * spiv restarts irssi [04:21] Well, the "good" news is that restarting irssi didn't magically make IRC stop lagging. [04:23] does it still lag with other clients? [04:28] * igc lunch [04:57] I just did a "bzr add" of some files I didn't really want to add. I've been stung in the past because iirc immediately doing "bzr remove" actually removed the file. how do I un-do the "add". I haven't committed yet [04:57] nealmcb: use Bazaar's remove command, but add the --keep option === samurai is now known as samiam [04:58] $ bzr rm --keep path/to/file/I/added/by/mistake.txt === samiam is now known as samurai [04:59] AfC: thanks. Last time I think I decided that --new would do that (Remove newly-added files) but --keep looks much better :) [04:59] Although as I read the help for remove in 1.7rc1 I see it say "--safe Only delete files if they can be safely recovered (default)." [04:59] What about "bzr revert"ing them? Would that work? [04:59] which would make me think that you would have been ok after all. === sdboyer is now known as sdboyer|zzz [05:00] Peng_: I imagine Bazaar would respond by complaining that the paths aren't versioned. (ie, "How can I revert a file to a state that I don't know about?"). But it might have special case logic. One way t find out. [05:01] Yeah, "revert" works [05:01] If "rm" deleted an unversioned file, that would be a bug. [05:01] Nice [05:09] also, I think bzr rm should act like revert, IMO. I don't know if it *does*, but it seems like a sensible default to me. [05:17] "bzr rm added-file" errors out with "bzr: ERROR: Can't safely remove modified or unknown files". [05:17] "bzr rm --keep added-file" works fine, just like revert. [05:18] Hmm, I should test "--new". [05:31] poolie: don't-sha-added-files is passing micro-tests, full run underway [05:31] -> lunch [05:40] lifeless, nice [05:54] * fullermd ponders. [05:54] 1.7 isn't yet, right? [05:54] Hm. Webiste doesn't like rc2 either. Wacky. [06:05] all tests pass. wahoo [06:34] lifeless, i was thinking of changing the test runner so that if a test fails it shows the stacktrace rightaway [06:34] rather than waiting til the suite has finished [06:48] poolie: as an option ? [06:53] if necessary [06:53] i find i'd often like to start looking at the first failure while it's running.... [06:54] I'm pretty sure I had a project once that output nothing at all, except error traces, and those as they happened [06:54] weirded people out [06:54] uhm [06:55] I'm personally pretty happy with the current behaviour, but then if I'm running either to get all the errors to filter, or with -1, as a general pattern [06:55] i can't parse that "either" [06:58] hi all ! [06:58] vila: good afternoon [06:58] I tend to run bzr selftest in one of a few modes [06:58] with -1, to find and debug a failure [06:58] without -1 to find all the failures (and I want a compact manner of inspecting them [06:58] without -1 on a small set of tests (found by the previous run) [07:00] I've mentioned before wanting to do a machine parsable output to file to automate this more [07:01] ok, same [07:01] I do the same. And when I get a small enough set of failing tests, I start putting some pdb.set_trace() [07:01] I don't know if this is optimal, or an accomodation of sorts [07:01] the main thing i want is to not have to wait until all of them run to find the rest [07:01] other data point is I run from within vim [07:01] so I'm always going to be waiting [07:01] possibly it would be better to write them either to a separate file (maybe in a subdirectory) [07:02] or to use tribunal or something [07:02] But sometimes, I wish I had the traceback for one of them. In that case I C-c and re-run only that tests with --starting-with [07:02] oh btw i have a vim tip [07:02] for when switching to another branch [07:02] do :1,9999bdel to remove everything already in memory [07:03] and avoid accidentally editing files from your old directory [07:03] poolie: heh, I don't need that [07:03] I suspect I use vim rather...differently to you [07:03] vila: I used --starting-with when writing the `branch --standalone` stuff, and it's much faster. Good job on that. :) [07:04] Odd_Bloke: you're welcome :) [07:04] probably [07:05] to start with i use gvim [07:05] Heresy! [07:05] quitting and restarting is adequate but it's nice to know an alternative [07:26] poolie: yahh, I use text vim, and many concurrent sessions [07:31] spiv: ping [07:42] jml: pong === Ng_ is now known as Ng [10:43] anyone know any good (semi idiot) tutorials on setting up bzr with pqm (ie automated gatekeeper workflow) [10:49] hi [10:50] how can i get all changed files since the init [10:50] or all changed files between two revisions [10:51] a_c_m: I don't know of one, sorry [10:51] james_w: yeah thats a shame... i'm googling for one now [10:52] dereine: "bzr status -r" may be what you want [10:52] e.g. bzr status -r2..3 [10:58] thx [10:59] how do i get the latest revision? [10:59] what do you mean? [11:00] the pqm docs include setup info; file bugs please if its not enough [11:00] dereine: '-1' refers to the tip revision [11:23] lifeless: maybe I didn't get what you mean with 'part of the target that pqm runs to run tests could update NEWS' [11:48] siretart: there is a Makefile [11:49] siretart: it has targets; one of those targets is dedicated to PQM, its the 'run this when doing a merge' target [11:49] siretart: I'm suggesting it can be extended to also update the NEWS file from the merge source (because its run in a tree with a pending merge, it can do $something to do this) [11:52] lifeless: okay. does this $something include the results of the testsuite? [11:53] siretart: no [11:53] siretart: I'm talking about the NEWS file [11:53] siretart: which is a problem for merges [11:53] okay. then I misunderstood you completely. ignore me then [11:53] siretart: I don't understand why you are talking about test suite output - its always all-pass because thats the policy for PQM [11:53] siretart: if it fails, we don't commit it [11:54] siretart: If Debian is packaging bzr with test failures, thats bad, and it should definitely stop doing that :P [11:56] last upload contained some known pycurl failures that I was told were harmless [11:57] they happen consistently on recent pycurls, I'm not convinced they are harmless [11:57] visik7: ^ [11:57] erm [11:57] vila: ^ [11:57] sorry visik7 [11:59] siretart: I am curious why you thought a thread about NEWS was related to Debian packaging ? [11:59] oops, community council meeting time, back later [12:02] lifeless: I was under the impression you wanted to include results of the testsuite to NEWS [12:03] wow [12:03] I guess its context [12:03] you may not but NEWS is a continual merge headache [12:04] because entries may merge ok but be in the wrong release etc [12:18] siretart: I'd be *very* interested about those pycurl failures, do you have some selftest output ? [12:20] not anymore, I removed the output some days after my upload [12:21] lifeless: see, it might make sense to install the selftest output in the package after all ;) [12:22] siretart: sure, I wasn't saying it was a bad idea, just totally confusing for me in that tread [12:22] yes, I was confused as well. sorry [12:22] siretart: it was a non sequiter :) [12:37] siretart: mail me the next time you run the test suite then :) === bac_afk is now known as bac [12:44] vila: there is a bug [12:45] lifeless: only one ? Gosh, we're close :) [12:47] lifeless: yes ? What bug ? [12:48] vila: on the pycurl failures [12:49] You can reproduce it ? [12:52] spiv can [12:53] I can't anymore; it got fixed AFAICT. [12:54] the poll/select one ? [12:54] Yep, that's the one I used to see. [12:54] a nightmare :) [12:54] siretart: how long ago was the upload? [12:54] Once I upgraded to hardy it popped up everywhere :) [12:55] lifeless: that was the last upload to debian experimental [12:55] siretart: not what, when [12:55] sep 5, 2008 [12:55] siretart: does it looks like bug #225020 ? [12:55] Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020 [12:55] I'm running the testsuite right now on my intrepid laptop [12:56] great [12:56] vila: yes, I think I've seen "select/poll returned error" back then [12:57] siretart: the bug is fixed in 1.7 but not in 1.6.1. I think intrepid uses the later [12:58] lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) > [12:58] s/>/?/ [12:59] vila: arh, don't think so. [13:00] lifeless: no urgency, that should be done carefully... [13:01] vila: what is your email adress? [13:01] v.ladeuil+lp at free.fr [13:02] vila: is the bug fixed? [13:03] lifeless: yes, it didn't dare reproduce anywhere AFAIK [13:05] lifeless: but note that it's fixed in 1.7 and pqm uses 1.6.1 if I'm correct [13:06] vila: errr [13:06] vila: it was removed from the pqm chroot, not from the bzr pqm uses [13:06] vila: two totally separate thing [13:07] I understand that [13:07] My point was that running the tests should not fail anymore, but merging before running the tests may [13:08] vila: my point is that the bzr doing the merging *still has pycurl* AFAIK [13:08] vila: and never had trouble merging [13:08] lifeless: then all is fine and I will cure my paranoia happily :) [13:09] * vila will try to better understand what run under the chroot and what doesn't another day :) [13:12] vila: 'make check' runs in teh chroot. Nothing else does [13:13] clear and simple, thanks [13:18] Hello all. Anyone got a good method for running the smart server as a service on a central ubuntu box? [13:22] Does anyone know how to do garbage collection in a shared repository after deleting unwanted branches? [13:23] pysquared: currently there isn't a simple answer; unless your branches are large I would say don't worry [13:23] This post https://lists.ubuntu.com/archives/bazaar/2007q3/031099.html mentions a "garbage collection" plugin, but provides no link, and I cannot find one. [13:24] pysquared: I don't think there is [13:25] I thought it would be nice to have a bzr2xyz (and back again) in a similar vein to http://msi2xml.sourceforge.net, to allow open-heart-surgery on a repo - anyone else thought this? === Snaury is now known as Snaury[away] [13:28] pysquared: thats roughly what fast-import|fast-export is, though note that *any* modification makes your content appear like new branches to others (its a distributed DB) [13:28] pysquared: rebase and similar tools are much more user friendly ways to make it hard for people to merge :P === bac is now known as bac_breakfast [13:29] For a technically minded newbie to bzr, I would also appreciate a program which would give me a nice view of a shared repo, all branches using it, orphaned heads etc., and it could be extended to show possible actions like commit, branch etc. [13:29] lifeless: thanks. checking out fast-[import|export] [13:33] branches rock ! [13:33] pysquared: qbzr|bzr-gtk|tbzr(windows) === tro|| is now known as tro [13:48] I'm on Ubuntu 8.04, so tbzr (TortoiseBZR?) is out. Just tried qbzr, feels a bit clunky though, you have to wrestle with it to get information out. [13:50] I have been using bzr-gtk (olive-gtk yes?) for a while, and it's better than qbzr IMVHO so far. [13:55] Thanks for the fast-import link, looks like a useful example of using bzrlib to disect a repo. === bac_breakfast is now known as bac [14:00] generally speaking, I just use bzrlib to work with repo's :) === dereine is now known as dereine[afk] [14:31] can I safely remove things in .bzr/repository/obsolete_packs (as the name would tend to imply)?? === bac is now known as bac_standup [14:39] lamont: removing the directory is not a good idea, but the contents of the directory will be safe to delete if your system didn't die before things were synced to disk [14:39] siretart: got your mail, I can confirm that bug #225020 is *not* fixed in bzr-1.6 nor bzr-1.6.1 :-/ [14:39] Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020 === bac_standup is now known as bac [14:50] jam: when you'll come online, are you aware of bug #269770 ? 1.7 may still find its way into intrepid... (me? trying to push a time-based release trough a Freeze exception ? me ?) [14:50] Launchpad bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] https://launchpad.net/bugs/269770 [14:52] james_w: thansk [15:00] Would a good method of cleaning out orphan revisions, i.e. garbage collecting (after deleting branch directories) be this: create a new shared repo, and branch every branch from old to new? [15:00] pysquared: yeah, that works [15:01] pysquared: it's obviously just a bit of a pain to do manually [15:08] vila meant: lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) ? [15:09] Tak: ? [15:09] hell, sorry [15:10] :) [15:10] script + scrollback = eek! === Verterok is now known as Verterok|out [15:24] vila: I'll be packaging 1.7 "now-ish" I don't know whether that means it will get merged or not. Certainly I would hope they do 1.6.1 [15:25] They mentioned 1.7, that's why I mentioned it to you, no pressure, at all, I swear :) [15:27] https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/269770 [15:27] Ubuntu bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] [16:04] why do I need to --force for a multi-branch merge? is it considered a bad idea? [16:06] Leonidas: well, the first merge will mean that there are files modified in the working tree, and merging in that state can be a headache, I don't know if there is more to it than that [16:07] james_w: ok, so it is just a human issue, not some technical problem. Thanks. [16:09] huh [16:09] bzr-svn seems to have replaced an svn revision [16:09] is this normal? [16:10] never done it before, but I haven't done this with the latest and greatest bzr-svn before [16:10] fdv, see the FAQ [16:10] oh [16:11] that was.. unexpected [16:12] jelmer: I had a bound branch, and the operation was a commit [16:12] unsure how to interpret the faq on that point [16:13] fdv, This happened after "bzr up" created pending merges I suspect? [16:13] jelmer: indeed' === sdboyer|zzz is now known as sdboyer [16:17] guilhembi: ping, I'd like to chat with you sometime about the 'bzr log file' changes [16:17] just to get a feel of someone outside the bzr project itself [16:19] jam: hi! good idea. We can IRC now. [16:20] Is this channel fairly quiet? [16:20] I haven't been watching [16:21] it is === dereine[afk] is now known as dereine [16:24] guilhembi: so here is my standard example for the 'bzr log file' situation: http://paste.ubuntu.com/49712/ [16:25] You have 3 branches, the one on the left (ABEG) is the mainline [16:25] guilhembi: do you understand the graph, in general? [16:27] ~/away [16:27] sorry :p === Verterok|out is now known as Verterok [16:28] reading [16:29] jam: yes; to be sure: the only changed of 'foo' is C, right? [16:29] s/changed/changer [16:30] guilhembi: right, that is the only *direct* change to the file. [16:30] ok [16:30] well, and "A" for introducing it [16:30] however, if you were to do "bzr diff" or E, or F, you would also see it "changing" C [16:30] because of the merge [16:32] jam: right, makes sense; E changed 'foo' compared to ancestor B. [16:32] due to merge. [16:32] and same for F [16:33]