On 5/20/05, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > > Imagine my surprise when the different branches weren't connected! > > And I was sure an earlier experiment had handled my branches properly.
I believe they should all be connected at the root (empty revision), but nowhere else. if they are not, it is a bug. > Err, crud. You're right. I hadn't actually looked at graydon's > change yet, thanks for pointing it out... This change is a problem, > because it means that we _have_ to support file suturing, in all its > icky glory, right from the get-go. Or else tell people that have > imported from cvs that sorry, they just can't do any merging, which > would be terrible. I do not immediately see the problem with suturing. there's a missing LCAD state S on your diagram, above A and B (else this degrades immediately to 2-way merge). on the S-D edge of the merge you have a composite edge saying "add foo" and on the S-E edge you have a composite edge saying "add foo, add bar". none of these 3 files can be identified -- the tids all have null names in S so cannot be name-compared for identification -- so you will be doing a fresh 2-way merge on the tree states. which is, I think, somewhat calm and non-pathological. probably, as usual, I'm missing the pathological case. > Surely we can do better than this? I _think_ cvs2svn does something > more sensible here, and it's solving exactly the same problem we are; > if someone could figure out how it handles this sort of wackiness, > that would be very helpful. hey, if they have an algorithm which actually works, by all means crib it. > It also seems like it would be _better_ than the current thing to just > make a guess at the branch-point -- basically, calculate exactly the > same manifests we calculate now, but instead of rooting them at the > tail ancestor, root them at the first commit on the branch we see. I considered doing this, but it really doesn't work: - there is no guarantee there ever was a commit "on the branch". the branch tag might be present in a file, but it could just be a tag hanging off the last-committed-trunk-version. this could be very old; you don't necessarily want to go all the way back to it. - there is no guarantee of a shared branching tree-order between files. I can just randomly branch-tag a file into branch B from branch C, and another file into B from A. we have a testcase from a real CVS repository which does this. - it is not what CVS does. if a branch tag is present in 5 of 10 files, checking out the branch is only supposed to check out those 5 files. not all 10, even if they were live when the branch was cut. I considered rooting the branch in the latest branchpoint in any of the affected files, and killing non-tagged files, but the second point killed that idea. I'm open to suggestions though. > This sort of "best effort" thing should be exactly correct for the > common case where people haven't done really clever things with their > CVS branches, and wouldn't be too bad for case where they have, > either. not true, alas: it constructs CVS states they don't want, notably at the head of their branch, then they file bugs. I figured it's better to have the present correctly accounted for, and the origins of the branch slightly fudged, than vice-versa. -graydon _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
