cvs synthetic branchpoint commits (was Re: cvsps wrapper script on mercurial@)

[John Hein]

Frank A. Kingswood wrote at 21:22 +0100 on Sep 29, 2009:
 > John Hein wrote:
 > > Frank Kingswood wrote at 13:30 +0100 on Sep 24, 2009:
 > >  > Greg Ward wrote:
 > >  > > 'hg convert' is, IMHO, not a good way to convert from CVS to
 > >  > > Mercurial.  In particular, if you care about accurate conversion of
 > >  > > tags and branches, 'hg convert' doesn't even try to handle all the
 > >  > > bizarre cases that you can see in real-life CVS repositories.
 > >  > 
 > >  > Well, the main thing that hg convert does not do so well is branches. It will 
 > >  > pull in all files changed on the branch, but get confused with the state of 
 > >  > the trunk (or parent branch) for files that are not branched.
 > >  > 
 > >  > It may be a reasonable goal to make convert do the right thing on these 
 > >  > non-branched files on a branch.
 > 
 > Hmmm, I've been trying but it seems to be much better now than when I 
 > first wrote it. I suspect the branch sort has the happy effect of fixing 
 > many of the issues.
 > 
 > > I tried to insert some code in cvs.py that generated a synthesized
 > > commit for each 'branchpoint'.  The synthesized commit, call it C, had
 > > as parents all the changesets that were marked as having the same
 > > branchpoint.  I was hoping that setting up the right parent/child
 > > relationship would just let the later toposort "do the right thing".
 > > 
 > > Then for commits that actually were made on the branch they were
 > > reparented to point to C.
 > > 
 > > But there was big trouble with lots of '(octopus merge fixup)' (from
 > > convert/hg.py).  So I've sort of given up on that approach.
 > > I was wondering if anyone has given it any thought.
 > 
 > It may be simpler to add new code in cvsps.py in the big while loop in 
 > createchangeset (starting around line 568), or just before it. This will 
 > allow debugging with hg debugcvsps instead of doing a conversion.
 > 
 > Can you post a test case (like tests/test-convert-cvs-*) that shows the 
 > problem? That will make debugging a lot easier.

Here you go (test script below)... a _very_ simple case with a single
file in cvs with two revs and a branch tag on the first rev.

As I mentioned, I "fixed" convert/cvs.py for this case so a synthetic
rev was added for the branch that was parented to the changeset(s)
with the cvs branchpoint.  And I reparented any children on the branch
(which the test case below does not have) to the branch synthetic rev.

But when there were more than one files in cvs tagged with the branch
tag (in various changesets), the parent list was > 1 resulting in
'(octupus merge fixup)' commits.  So I considered that the approach to
parent the synthetic branch rev to all changesets with the branchpoint
(in order to get the synthetic branch rev in the "right" place) to be
the wrong way to go.  And that's when I asked here for hints.  So be
aware that if you fix this simple test case, then start adding
changesets on the branch both with and without committed changes on
the branch in cvs.

That said, fixing this simple test case seems like a good place to
start!

============
% cat test-convert-cvs-branch-no-revs
#!/bin/sh

# die on any failure
set -e

mkdir /tmp/test-convert-cvs-branch-no-revs || exit 1
cd /tmp/test-convert-cvs-branch-no-revs

echo "building cvs repo..."
export CVSROOT=$PWD/root
unset CVSREAD
cvs -q init
(mkdir tmp
cd tmp
cvs -q co -l .
mkdir mod
cvs -q add mod
cd mod
echo 0 > x
cvs -q add x
cvs -q ci -m 0 x
cvs -q tag -b b1
echo 1 > x
cvs -q ci -m 1 x)
# we now have a cvs repo with module 'mod', file 'x'
# with two revs and a branch tag, 'b1', on the first rev

echo "converting cvs repo to hg..."
hg convert --config convert.cvsps.cache=0 tmp/mod mod-hg
cd mod-hg
hg up -r b1 || { echo "update to branch failed - bad convert?" >&2; exit 1; }
============