Re: [PATCH] cvsps/cvsimport: fix branch point calculation and broken branch imports

> David Mansfield wrote:
> > The main issue with git-cvsimport stems from an unfixable problem.
> > cvsps's design goal is to show commits in chronological order.  Based
> > solely on this data, it's impossible to always reconstruct a branch
> > point (or a tag) since a person could have committed files after someone
> > else's commit, but not done an update then tagged.  
> 
> Just to be more explicit, I think you are talking about a situation like
> this:
> 
> 1. Add file1:1.1 and file2:1.1 to repository.
> 2. User1 modifies file1 and commits file1:1.2.
>    ...some non-negligible amount of time passes...
> 3. User2 modifies file2 and commits file2:1.2.
> 4. User2, without updating file1 to revision 1.2, adds a tag.
> 
> This results in a tag that refers to file1:1.1 and file2:1.2, even
> though those two revisions never appeared in the repository at the same
> time.
> 

> > So some files are from before the 'other' user's commit, and some files
> > after.  What can you do?  
> 
> You can do the only thing that is consistent with the CVS
> history--create the tag not from a single source revision but from
> multiple revisions.  Unfortunately, git cannot handle this directly, but
> there is a workaround using a "fixup branch" [1].
> 
> cvs2svn/cvs2git [2] creates a "fixup branch", copies file1:1.1 and
> file2:1.2 onto that branch, then creates the tag from the fixup branch.
>  This ensures that checking the tag out of git gives the same file
> contents as checking the tag out of CVS.  I think that git-cvsimport
> gets this wrong (!?!)
> 
> It is your framing of the problem that is leading to the impossibility.
>  CVS's design does *not* require that a tag or branch is created in a
> single commit, nor that it is created from a single source revision.
> Trying to impose these artificial constraints means that the resulting
> git repository is inconsistent with the CVS repository in quite common
> circumstances.
> 

> > It's not per se a flaw in cvsps, it always wanted to show commits in
> > chronological order, but it is a severe limitation in using cvsps to
> > generate changesets for git.
> 
> cvs2git always creates commits in chronological order too, but its
> output is by design always consistent with the CVS record.
> 

> > By engineering a direct tool (such as parsecvs, I presume) these
> > obstacles can be overcome by constructing some commits that were never
> > made by the actual users of the cvs repo in order to get it right.
> > 
> > I'm not sure exactly how this is done, because I've never looked at
> > parsecvs.
> 
> cvs2git's design is documented quite extensively, if you are interested
> [3].  Parsecvs, AFAIK, uses a similar approach.
>