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

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Mon, 23 May 2005 00:39:07 +0200, Graydon Hoare 
<address@hidden> said:

graydon.hoare> On 5/20/05, Nathaniel Smith <address@hidden> wrote:
graydon.hoare> 
graydon.hoare> > > Imagine my surprise when the different branches
graydon.hoare> > > weren't connected!  And I was sure an earlier
graydon.hoare> > > experiment had handled my branches properly.
graydon.hoare> 
graydon.hoare> I believe they should all be connected at the root
graydon.hoare> (empty revision), but nowhere else. if they are not, it
graydon.hoare> is a bug.

I guess I was seeing it as monotone-viz shows it :-).

graydon.hoare> > Surely we can do better than this?  I _think_ cvs2svn
graydon.hoare> > does something more sensible here, and it's solving
graydon.hoare> > exactly the same problem we are; if someone could
graydon.hoare> > figure out how it handles this sort of wackiness,
graydon.hoare> > that would be very helpful.
graydon.hoare> 
graydon.hoare> hey, if they have an algorithm which actually works, by
graydon.hoare> all means crib it.

Looking at it (too?) as well as cvsps.  Hopefully, I can get something
sensible out of it.  The real pisser is what CVS does if the first
commit is an import to the vendor branch...

graydon.hoare> > It also seems like it would be _better_ than the
graydon.hoare> > current thing to just make a guess at the branch-
graydon.hoare> > point -- basically, calculate exactly the same
graydon.hoare> > manifests we calculate now, but instead of rooting
graydon.hoare> > them at the tail ancestor, root them at the first
graydon.hoare> > commit on the branch we see.
graydon.hoare> 
graydon.hoare> I considered doing this, but it really doesn't work:
graydon.hoare> 
graydon.hoare> - there is no guarantee there ever was a commit "on the
graydon.hoare>   branch". the branch tag might be present in a file,
graydon.hoare>   but it could just be a tag hanging off the
graydon.hoare>   last-committed-trunk-version. this could be very old;
graydon.hoare>   you don't necessarily want to go all the way back to
graydon.hoare>   it.

I don't understand why the age of some specific commit is important.
As to empty branches, you might simply choose to ignore them
entirely.  I dunno about you, but I find it sensible.  Either such a
branch was created and then ignored, or it's very fresh and can very
easily be recreated.  Of course, monotone should issue a warning to
the user when that happens.

graydon.hoare> - there is no guarantee of a shared branching
graydon.hoare>   tree-order between files. I can just randomly
graydon.hoare>   branch-tag a file into branch B from branch C, and
graydon.hoare>   another file into B from A. we have a testcase from a
graydon.hoare>   real CVS repository which does this.

As a CVS admin, I'd call that abuse of the system.  I know it's
possible to do that, and I'd consider that a malformed CVS module.  I
wonder how cvs2svn and cvsps would handle such a case,  It might be
among those where they'd simply give up or fsck up.

That real CVS repository, is it a publically reachable one (appologies
if I've missed the message about it earlier)?  I might consider
playing with cvsps or cvs2svn with it and see what happens...

graydon.hoare> - it is not what CVS does. if a branch tag is present
graydon.hoare>   in 5 of 10 files, checking out the branch is only
graydon.hoare>   supposed to check out those 5 files. not all 10, even
graydon.hoare>   if they were live when the branch was cut.

I'm quite sure cvs2svn treats that by adding a first revision on the
branch that deletes those files that doesn't belong in the branch.

graydon.hoare> I considered rooting the branch in the latest
graydon.hoare> branchpoint in any of the affected files, and killing
graydon.hoare> non-tagged files, but the second point killed that
graydon.hoare> idea. I'm open to suggestions though.

I think those are exactly what you should do.  Salvaging malformed CVS
repositories could be considered impossible for not.  I would much
prefer to see something that helps in 90% of the cases than not at
all.  The current state of cvs_import strikes me as much too close to
"not at all".

graydon.hoare> > This sort of "best effort" thing should be exactly
graydon.hoare> > correct for the common case where people haven't done
graydon.hoare> > really clever things with their CVS branches, and
graydon.hoare> > wouldn't be too bad for case where they have, either.
graydon.hoare> 
graydon.hoare> not true, alas: it constructs CVS states they don't
graydon.hoare> want, notably at the head of their branch, then they
graydon.hoare> file bugs. I figured it's better to have the present
graydon.hoare> correctly accounted for, and the origins of the branch
graydon.hoare> slightly fudged, than vice-versa.

What kind of CVS states does it construct?  While playing with
cvs2svn, I found some extra states in the dump file, having one of the
following comments each ({tag} is some tag name, {rev} is a revision
number):

 This commit was manufactured by cvs2svn to create branch '{tag}'

 This commit was manufactured by cvs2svn to create tag '{tag}'.

 This commit was generated by cvs2svn to compensate for changes in {rev},
 which included commits to RCS files with non-trunk default branches.

Is that the kind of thing you're talking about?

Cheers,
Richard

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis