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