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

[Frank Kingswood]

John Hein wrote:
> Frank A. Kingswood wrote at 20:20 +0100 on Sep 30, 2009:
>  > Well this is a start. A patch for this is attached to give an idea.
>  > 
>  > But it sadly leads to new problems.
>  > o  9[tip]:0   0056697a62d5   2009-09-30 20:06 +0100   frank
>  > |    convert-repo: CVS branchpoint b2
>  > |
>  > | o  8   22a76c959ab4   2009-09-30 20:06 +0100   frank
>  > | |    modify f1
>  > | |
>  > | o  7   9bae17743cb1   2009-09-30 20:06 +0100   frank
>  > | |    add f3
>  > | |
>  > | o  6   63b2ef861a90   2009-09-30 20:06 +0100   frank
>  > | |    add f2
>  > | |
>  > | o  5:0   aceb0fb57a15   2009-09-30 20:06 +0100   frank
>  > |/     add f1
>  > |
>  > | o  4   c983529840c8   2009-09-30 20:06 +0100   frank
>  > | |    modify f4
>  > | |
>  > | o  3   4988cbf8941b   2009-09-30 20:06 +0100   frank
>  > | |    add f6
>  > | |
>  > | o  2   e5330a1eaa8f   2009-09-30 20:06 +0100   frank
>  > | |    add f5
>  > | |
>  > | o  1   b283b6221e1d   2009-09-30 20:06 +0100   frank
>  > |/     add f4
>  > |
>  > o  0   fbbab430f796   2009-09-30 20:06 +0100   frank
>  >       add f0 on trunk
>  > 
>  > 
>  > You see that the parent of revision 9 is revision 0, not revision 6 as 
>  > expected. The reason for that is that the branch changesets created are 
>  > placed as early as possible in the list of changesets, instead of as 
>  > late as possible.
>
> I would have thought rev 5, not 6, since f2 should not be on b2.
>   
Yes, you're right there.
> After my reparenting false start, my thought was that this is really
> just a sorting issue.  Except for some missing branch changesets, the
> changesets are all there and right.  But having them sorted properly
> so they are committed to hg in the right order before adding a branch
> commit (which I still think will be necessary) is important.  What
> about overriding the sorting done in convert to be specific to CVS?
>   
There's no need for that. When we are in createchangeset() we can do 
anything we want with the list of changesets. We already re-sort it once 
as it is first sorted by changeset, and later by date.
> It seems to me that somehow the synthetic branch commit for branch
> 'foo' in hg needs to be done just after all changesets marked with
> 'Branchpoint: foo' (in cvsps output) have been committed.
>
> If we can have this happen by sorting changesets properly, I
> think that would be ideal and fast.
>   
Would you be able to experiment with that? just add your own sorting 
comparison function and sort the changesets. It is then probably better 
if the new experimental branchpoint code is moved before tags 
collection, so we do not have to re-sort the list twice.
> The only question I have is what happens with real CVS repos
> that have twisty complicated branching.
>   
It is not difficult to create a cvs repository with loops and other 
disasters. But I'm optimistic that this is not all that common, and 
fixing the common cases is more urgent.

Frank

-- 
------------------------------------------------------------------------
Frank A. Kingswood                      frank at kingswood-consulting.co.uk
Cambridge, United Kingdom                               +44-870-095 0000