[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] About the recent change of cvs_import...
From: |
Richard Levitte - VMS Whacker |
Subject: |
Re: [Monotone-devel] About the recent change of cvs_import... |
Date: |
Mon, 23 May 2005 05:35:24 +0200 (CEST) |
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