Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

"Eric S. Raymond" <esr@thyrsus.com> writes:

I see an opening for smoother transition here.

Like it or not, you cannot force distros to ship with cvsps 3.0 when we ship our 1.8.2 (or 2.0 or whatever) that includes a cvsimport that requires cvsps 3.0. The best we can do is to make it capable of working with cvsps 3.0 for a better result (when available), and working with cvsps 2.0 in a limited way as ever (linear history only, etc. etc.) when cvsps 3.0 is not available.

As your version already knows how to detect the case where cvsps is too old to operate with it, I imagine it to be straight-forward to ship the old cvsimport under obscure name, "git cvsimport--old" or something, and spawn it from your version when necessary, perhaps after issuing a warning "cvsps 3.0 not found; switching to an old and unmaintained version of cvsimport..."

That way, people who have been happily working with linear CVS histories with the old limited tool can keep using the same set-up until their distro update their cvsps, without harming people who need to work with more complex CVS histories, who can choose to update their cvsps early themselves as $HOME/bin/cvsps earlier on their $PATH.

By "cvsimport" (the current version), we are talking about a piece of software that has been used in the field for more than 5 years, still with a handful of patches to enhance it in the past two years. A flag-day "this hot-off-the-press version is infinitely better" replacement is not an option, especially when we can expect that existing users are not asking for an "inifinitely better" version (they rather prefer "stable" in the "works just as before" sense), even when the hot-off-the-press version *is* infinitely better in some use cases such as dealing with branchy histories.