[PATCH 0 of 1] convert: better support for CVS branchpoints (issue1447)

Henrik Stuart hg at hstuart.dk
Sun Jun 7 12:27:58 UTC 2009


This is the second attempt at introducing better branch point support,
i.e. trying to solve issue 1447. However, as Michael Haggerty has
pointed out [1], cvsps is inherently flawed in its conversion, and the
more I try to patch it up, the more apparent this fact becomes.
Unfortunately, the alternative, cvs2svn, does not easily accomodate
CVSNT's extensions that I am fairly interested in.

To illustrate (one of) the problem(s), there is a short note in the
patch on why the changeset construction can still yield inaccurate
history - in fact it may generate history that is objectively wrong,
e.g. including file revisions on a branch that it was never on.

The only correct approach would be to do away with the simplistic
changeset construction, build a dependency graph for file revisions
(possibly using the commitid extra field if present - it's been in CVS
since Feb 2005 and CVSNT at least since July 2006 - couldn't find any
older version of CVSNT than that), conflate file revisions belonging
to the same changeset (as per what CVS thinks belongs together), take
the resulting dependency graph, break cycles by separating changes,
and then generating the changesets, which, of course, is pretty much
what cvs2svn is doing.

Also, as can be seen from the patch, the output of
test-convert-cvs-builtincvsps has changed such that the converted
repository has two different roots, even though they should be
related. This is due to the fact that the branch point is two
different changesets (as one of the files has been updated independent
of the other before making the branch) - and cvsps has no provision
for adding a compensating changeset as is required here (namely
undoing the change to one file before branching off to a named
branch). Thus, the branch point support will make branches more
correct, but probably introduce more conversions with multiple roots,
so at least it becomes more apparent where cvsps fails miserably.

I honestly don't think any amount of hackery on the cvsps solution
(short of reimplementing cvs2svn) will be adequate, unfortunately. CVS
is simply too alien for a naive conversion to work well.

[1]: http://www.selenic.com/pipermail/mercurial-devel/2009-April/011800.html

-- 
Kind regards,
  Henrik Stuart


More information about the Mercurial-devel mailing list