| Kamping_Kaiser | does anyone know if the bzr-builddeb project is still ticking? | 01:48 |
|---|---|---|
| jelmer_ | Kamping_Kaiser, yep, very much so | 01:23 |
| Kamping_Kaiser | jelmer_: ok, cheers | 01:24 |
| 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 | 04:50 |
| 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:02 | |
| 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 | 05:03 |
| TzilTzal | Does anyone know how bzr finds the BASE version during a merge? | 07:28 |
| fullermd | It's the LCA of the branches. | 07:30 |
| TzilTzal | so how could a criss cross ever occur if that was the case? | 07:35 |
| 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:41 |
| 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:48 |
| 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:49 |
| 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. | 07:50 |
| TzilTzal | anyone? | 08:14 |
| fontanon | Hi everybody! Does anyone had some experiences migrating from bazaar to git with fast-export/import ? | 10:34 |
| === Meths_ is now known as Meths | ||
| TzilTzal | anyone knows how bzr finds the BASE version in a merge? | 13:48 |
| GungaDin | does anyone have any idea how bzr finds the BASE version during a merge? | 22:57 |
| bob2 | http://doc.bazaar.canonical.com/latest/developers/lca_tree_merging.html perhaps | 22:58 |
| GungaDin | doesn't that apply only to -lca? | 23:00 |
| spiv | GungaDin: well, the merge base is the Latest Common Ancestor | 23:03 |
| spiv | Although that doc is about the case where there are multiple revisions matching that description. | 23:04 |
| 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:05 |
| spiv | GungaDin: Well, look at the revision graph in that link | 23:06 |
| spiv | (And also see the text at http://doc.bazaar.canonical.com/latest/en/user-reference/criss-cross-help.html) | 23:07 |
| GungaDin | spiv - so after a merge from A to B the latest common ancestor is that commit" | 23:11 |
| GungaDin | ? | 23:11 |
| 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:16 |
| 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:19 |
| 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:20 |
| GungaDin | that's sort of what I thought.. but with this case, how could you have a criss cross merge then? | 23:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| spiv | Their own branch does. | 23:31 |
| spiv | "bzr commimt | 23:31 |
| 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:32 |
| spiv | But has a copy of Claire's branch at the time he left to catch the plane. | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!