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