Re: Fwd: git cvsimport implications

[John Keeping <john@keeping.me.uk>]

On Fri, May 17, 2013 at 11:10:03AM +0200, Michael Haggerty wrote:
> On 05/15/2013 08:03 PM, Eugene Sajine wrote:
> > My primary goal was to understand better what are the real problems
> > that we might have with the way we use git cvsimport, so I was not
> > asking about the guarantee of the cvsimport to import things
> > correctly, but if there is a guarantee the import will result in
> > completely broken history.
> 
> So what are you going to do, use cvsimport whenever you cannot *prove*
> that it is wrong?  You sure have low standards for your software.
> 
> The only *useful* guarantee is that software is *correct* under defined
> circumstances.  I don't think anybody has gone to the trouble to figure
> out when that claim can be made for cvsimport.
> 
> > If the cvsimport is that broken - is there any plan to fix it?
> 
> For one-time imports, the fix is to use a tool that is not broken, like
> cvs2git.
> 
> Alternatively, Eric Raymond claims to have developed a new version of
> cvsps that is not quite as broken as the old version.  Presumably
> cvsimport would be not quite as broken if used with the new cvsps.

cvsimport doesn't work with the cvsps-3 - we decided to stick with the
version we have (using cvsps-2) because that is the only option that
supports incremental import; those using if for that are used to its
deficiencies and there is no plan to improve it.  The manpage notes that
it uses a deprecated version of cvsps and recommends alternatives for
one-shot imports.

There is a version of git-cvsimport script in the cvsps-3 repository
that works with it, but it does not support incremental import in the
same was as git.git's git-cvsimport so it will not replace the version
in git.git.