[01:48] does anyone know if the bzr-builddeb project is still ticking? [01:23] Kamping_Kaiser, yep, very much so [01:24] jelmer_: ok, cheers [04:50] bzr hung up ~9 revisions short branching from an svn repo. is there some way i can finish it? pull/merge/up/co all throw errors [05:02] Kamping_Kaiser, what sort of errors? [05:02] Kamping_Kaiser, you can perhaps "bzr pull -r-9" [05:02] * jelmer_ gets sleep [05:03] jelmer_: 'Not a branch' or 'No WorkingTree exists for' file:///home/kgoetz/sourcecheckouts/debian-installer/.bzr/checkout/ [05:03] jelmer_: sleep well [07:28] Does anyone know how bzr finds the BASE version during a merge? [07:30] It's the LCA of the branches. [07:35] so how could a criss cross ever occur if that was the case? [07:41] Well, in the case of a criss-cross, there isn't a unique LCA. [07:41] I dunno what (or if) bzr puts in .BASE then. [07:48] I think by definition there has to be one LCA [07:48] a criss cross is when there isn't a unique BASE... [07:48] but I don't know how this BASE is found. [07:48] Well, semantics. [07:48] heh [07:49] well, that's what I'm asking. how doe bzr find BASE? [07:49] 'cuz I"m a bit confused about criss crosses and what could cause them, really.. [07:49] I'm not sure what it calls BASE in the case of a crisscross. Probably just walks back until it finds a real unique LCA. [07:50] Which would be [much] farther back than the set of CA's the criss-cross gives. [07:50] that could depend on the resolution algorithm. [07:50] but I'm talking about just finding any BASE. [08:14] anyone? [10:34] Hi everybody! Does anyone had some experiences migrating from bazaar to git with fast-export/import ? === Meths_ is now known as Meths [13:48] anyone knows how bzr finds the BASE version in a merge? [22:57] does anyone have any idea how bzr finds the BASE version during a merge? [22:58] http://doc.bazaar.canonical.com/latest/developers/lca_tree_merging.html perhaps [23:00] doesn't that apply only to -lca? [23:03] GungaDin: well, the merge base is the Latest Common Ancestor [23:04] Although that doc is about the case where there are multiple revisions matching that description. [23:05] that's actually the reason I'd like to know. I don't understand exactly what would cause a criss cross (i.e. multiple BASEs)... [23:05] ll [23:05] (oops) [23:06] GungaDin: Well, look at the revision graph in that link [23:07] (And also see the text at http://doc.bazaar.canonical.com/latest/en/user-reference/criss-cross-help.html) [23:11] spiv - so after a merge from A to B the latest common ancestor is that commit" [23:11] ? [23:16] GungaDin: I don't know what you mean by "A" and "B" [23:16] branches [23:16] GungaDin: perhaps the first bit of http://revctrl.org/CrissCrossMerge will help [23:19] GungaDin: an intuitive (rather than formal and precise) description of the merge base for merging A into B would be "the most recent revision in A that is already in B." [23:20] GungaDin: because when the user asks bzr to do a merge of A into B, they presumably want all the "new" revisions from A, the revisions that B doesn't have yet. [23:21] that's sort of what I thought.. but with this case, how could you have a criss cross merge then? [23:22] GungaDin: well, as you can see from e.g. that CrissCrossMerge page, if A has been merged into B at the same time as B has been merged into to A, you don't have a clear choice of merge base. [23:23] How can they exactly both be done together, really? [23:23] One way to think about it is both branches have a revision that merged b1 with c1, but they quite possibly resolved the merge differently. [23:24] So now when you merge those new revisions with each other, which resolution should "win"? [23:24] GungaDin: look at the diagram and story on the CrissCrossMerge page. [23:24] I understand the reasoning of what you're saying.. but can't completely understand how it could happen with the way of finding BASE [23:26] Well, you tell me which of [a, b1, b2, c1, c2] should be the base for a merge of b2 with c2? [23:26] I can't completely understand how you can both merge from and to a branch at the same time. [23:26] I thought it was also locked for changes during that time [23:26] There are two branches [23:26] Which means two independent sets of changes. [23:26] yes [23:26] In this example, Bob has one branch and Claire has the other [23:27] Perhaps Bob and Claire typed "bzr merge" truly simultaneously. [23:27] Perhaps Claire's mirror of Bob's branch was slightly out of date [23:28] There's no locking that prevents that. [23:28] but when they're trying to merge "simultaneously", wouldn't one branch get locked so the other can't merge? [23:29] No. [23:29] Just because someone's branch is write-locked doesn't mean I can't read to it. [23:29] (What if they are pushing over a really slow connection? I wouldn't want to be prevented from reading the revisions that were already there.) [23:30] I'm talking about writing. You wouldn't be able to commit at the same time. [23:30] Or perhaps one or both of these people were working offline at the time. [23:30] They aren't committing to the same branch! [23:30] There are *2* branches. [23:30] yes. [23:30] Owned by different people (in this example, and usually in practice) [23:30] one you start a commit, don't they get write locked? [23:31] Their own branch does. [23:31] "bzr commimt [23:32] "cd mybranch; bzr merge $other_branch; bzr commit" never write-locks $other_branch at all. [23:32] Why would it? It never writes to other_branch. [23:32] no, I didn't mean exactly that.. anyway, that's fine. [23:32] Keep in mind also that there can be many copies of a branch: perhaps Bob is on an airplane, and working offline. [23:32] this is a simple case though. [23:33] But has a copy of Claire's branch at the time he left to catch the plane.