Junio C Hamano <gits...@pobox.com> writes:
> Jonathan Nieder <jrnie...@gmail.com> writes:
>> Michael Haggerty wrote:
>>> Regarding your claim that "within a few months the Perl git-cvsimport is
>>> going to cease even pretending to work": It might be that the old
>>> git-cvsimport will stop working *for people who upgrade to cvsps 3.x*.
>>> But it is not realistic to expect people to synchronize their git and
>>> cvsps version upgrades. It is even quite possible that this or that
>>> Linux distribution will package incompatible versions of the two packages.
>> Moreover, I feel an obligation to point the following out:
>> In a hypothetical world where cvsps 3.x simply breaks "git cvsimport"
>> it is likely that some distributions would just stick to the existing
>> cvsps and not upgrade to 3.x. Maybe that's a wrong choice, but that's
>> a choice some would make. An even more likely outcome in that
>> hypothetical world is that they would ship it renamed to something
>> like "cvsps3" alongside the existing cvsps. Or they could rename the
>> old version to "cvsps2". If we were the last holdout, we could even
>> bundle it as compat/cvsps.
>> So please do not act as though the cvsps upgrade is a crisis that we
>> need to break ourselves for at threat of no longer working at all.
>> The threat doesn't hold water.
>> Luckily you have already written patches to make "git cvsimport" work
>> with cvsps 3.x, and through your work you are making a better
>> argument: "The new cvsimport + cvsps will work better, at least for
>> some users, than the old tool."
>> Just don't pretend you have the power to force a change for a less
>> sensible reason than that!
> After a quick survey of various distros, I think it is very unlikely
> that we will see "distros move on to newer cvsps, leaving cvsimport
> broken" situation. If anything, it is more like "distros decide to
> ignore the new cvsps, until it is made to work with cvsimport" [*1*].
> I think it is probably sensible to rename the current cvsimport to
> cvsimport-2, write a small wrapper git-cvsimport.sh which is
> something like this:
> ----- >8 -----
> if test -z "$GIT_CVSPS_VERSION"
> case "$(cvsps -h 2>&1 | grep 'cvsps version')" in
> if test -z "$GIT_CVSPS_VERSION"
> echo >&2 "No supported cvsps available"
> exit 1
> exec git cvsimport-$GIT_CVSPS_VERSION "$@"
> ----- 8< -----
> and put Eric's one as git-cvsimport-3 (after ripping out the code to
> fallback to the old cvsimport). The longer term trend will be to
> move away from cvsimport-2, as it is unlikely cvsps-2.x will gain
> improvements, if any; keeping fallback code outside cvsimport-3 will
> be a better first step in the healthier long term code evolution.
> We will keep the current t96xx series of tests, and have them export
> GIT_CVSPS_VERSION=2 at the beginning, protect them with test prereq
> that requires presence of cvsps 2.x; this will still make sure that
> the current cvsimport users will not see any regressions.
> Eric's one should be polished enough to produce good results on the
s/should be polished enough/should be in a polished enough state/
that is. Also "if not right now" may better convey what I meant if
written "if not already".
> simpler sample CVS histories t96xx deal with soonish if not right
> now, so we can use a method similar to how we shared tests between
> blame and annotate while both were _different_ implementations to
> make sure the newer blame did not inroduce regression by running the
> same set of tests. Where the result _ought_ to differ, we should
> also add tests that work only with the new cvsimport, of course.
> I could help getting the ball rolling on this, if everybody agrees
> that the above is a sensible direction to go, given the real world
> constraints of distro inertia.
> *1* Fedora, Debian and Ubuntu do not even have cvsps 3.x in their
> bleeding edges, OpenBSD and NetBSD do not seem to have it either,
> and Gentoo and ArchLinux have the cvsps 3.x blocked due to
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