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
> 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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html