On Thu, Mar 05, 2009 at 04:18:46PM +0100, Michael Haggerty wrote:
> In all of these cases *the git content is objectively wrong*. These are
> not quality-of-conversion quibbles, they are egregious correctness
> problems that will occur in most nontrivial CVS repositories.
Thanks for the detailed descriptions. I don't think anyone is denying
that the results are objectively wrong; it is clear that cvsimport
doesn't handle complex cases well.
> IMHO there are only two intellectually honest alternatives:
>
> 1. Commit the new tests in the hope that somebody will try to fix them,
> which probably requires ditching cvsps and starting almost from scratch.
> Until they are fixed add a disclaimer, in big red letters, to the
> git-cvsimport documentation, saying that it *should not be trusted* to
> make accurate conversions (though it might be useful in very restricted
> scenarios requiring incremental synchronization with a CVS repo). In
> this case the tests should be retained as documentation, though perhaps
> they should not be run unless the user turns on a particular flag.
I think committing the tests and putting a big warning onto cvsimport
are two separate things. I don't want to hide the fact that cvsimport
sucks, and I don't think anyone does. But I also don't want to bog down
the test suite with useless cruft that nobody is actually going to look
at.
I think your suggestion of disabling the tests unless flagged is
reasonable. The tests themselves don't take up much space in the
repository, it's only running them that is painful.
As far as marking cvsimport with a disclaimer, I don't have an objection
to warning people in the documentation. It seems like most people who
come to the list with a cvsimport problem end up getting the advice to
try something else, and then they end up happy. Putting a
not-inflammatory disclaimer into the documentation to check results and
to consider some other options would save the list a little work.
> 2. Remove the git-cvsimport command altogether.
I don't think this is a good idea. It still has two uses which make it
better than nothing:
1. It's the only (AFAIK) importer that is incremental. When you are
tracking relatively simple development on an existing CVS repo,
it is the only choice. Taking that choice away seems
counterproductive.
2. It _does_ work on relatively mundane cases, and there _are_ mundane
CVS repositories. Yes, other tools can also handle these cases, but
using the bundled cvsimport is much easier using an intermediate
svn.
I am less sure of (2) above, because naive users might not _know_ that
they're screwing up their repository. So safety would dictate spending
the extra effort (which is the point you were making, I think).
But certainly cvsimport should hang around for (1), even it is with a
disclaimer.
For how long, I don't know. It seems like most people are putting their
CVS repos to rest at this point, moving at least to SVN. I know there
will be people hanging on to CVS for at least a decade, but I'm not sure
at what point we say "there are not enough of you to care; go use a less
convenient one-time tool". cvsimport is already suffering from bit-rot
as people who like git enough to work on it converted their repos years
ago.
-Peff
--
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
