Re: Fwd: git cvsimport implications

From: John Keeping <john@keeping.me.uk>
Date: May 17, 2013, 09:21 UTC
Message-ID: <20130517092157.GA2299@serenity.lan>
In-Reply-To: <5195F3EB.8000308@alum.mit.edu>

On Fri, May 17, 2013 at 11:10:03AM +0200, Michael Haggerty wrote:

Show 22 quoted lines

> 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.