Re: [Monotone-devel] About the recent change of cvs_import...

[Graydon Hoare]

On 5/20/05, Nathaniel Smith <address@hidden> 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