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

[Frank A. Kingswood]

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.

Frank