git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	"Eric S. Raymond" <esr@thyrsus.com>,
	git@vger.kernel.org, Chris Rorvick <chris@rorvick.com>
Subject: Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
Date: Sun, 13 Jan 2013 14:20:09 -0800	[thread overview]
Message-ID: <7v8v7wiv3a.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130112182649.GC4624@elie.Belkin> (Jonathan Nieder's message of "Sat, 12 Jan 2013 10:26:49 -0800")

Jonathan Nieder <jrnieder@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 -----
#!/bin/sh

if test -z "$GIT_CVSPS_VERSION"
then
	case "$(cvsps -h 2>&1 | grep 'cvsps version')" in
        2.*)
		GIT_CVSPS_VERSION=2
                ;;
	3.*)
		GIT_CVSPS_VERSION=3
                ;;
	esac
fi

if test -z "$GIT_CVSPS_VERSION" 
then
	echo >&2 "No supported cvsps available"
	exit 1
fi

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
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.

Agreed?


[References]

*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
incompatiblity.

http://pkgs.fedoraproject.org/cgit/cvsps.git/
http://packages.debian.org/search?keywords=cvsps
http://packages.ubuntu.com/search?keywords=cvsps

http://packages.gentoo.org/package/dev-vcs/cvsps
https://bugs.gentoo.org/show_bug.cgi?id=450424

https://bugs.archlinux.org/task/33363?project=1&cat%5B0%5D=2&string=cvsps

  reply	other threads:[~2013-01-13 22:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11  3:32 [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs Junio C Hamano
2013-01-11 16:31 ` Junio C Hamano
2013-01-11 18:58   ` Eric S. Raymond
2013-01-11 19:17     ` Junio C Hamano
2013-01-11 19:27     ` Junio C Hamano
2013-01-12  5:04       ` Eric S. Raymond
2013-01-12  5:20 ` Junio C Hamano
2013-01-12  5:38   ` [PATCH] t/t960[123]: remove leftover scripts Junio C Hamano
2013-01-12  6:06     ` Chris Rorvick
2013-01-12  8:40   ` [PATCH] t/lib-cvs: cvsimport no longer works without Python >= 2.7 Junio C Hamano
2013-01-12 15:27     ` Michael Haggerty
2013-01-13 17:17       ` John Keeping
2013-01-12 15:47   ` [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs Eric S. Raymond
2013-01-12 15:13 ` Michael Haggerty
2013-01-12 16:11   ` Eric S. Raymond
2013-01-12 18:16     ` Jonathan Nieder
2013-01-12 18:26   ` Jonathan Nieder
2013-01-13 22:20     ` Junio C Hamano [this message]
2013-01-13 23:27       ` Junio C Hamano
2013-01-14  1:40       ` [PATCH 0/3] A smoother transition plan for cvsimport Junio C Hamano
2013-01-14  1:40         ` [PATCH 1/3] cvsimport: allow setting a custom cvsps (2.x) program name Junio C Hamano
2013-01-14  1:40         ` [PATCH 2/3] cvsimport: introduce a version-switch wrapper Junio C Hamano
2013-01-14  1:47           ` Junio C Hamano
2013-01-14  1:40         ` [PATCH 3/3] cvsimport: start adding cvsps 3.x support Junio C Hamano
2013-01-15  6:19           ` Chris Rorvick
2013-01-15  6:44             ` Junio C Hamano
2013-01-14  5:12       ` [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs Michael Haggerty
2013-01-14  7:25       ` [PATCH v2 0/6] A smoother transition plan for cvsimport Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 1/6] Makefile: add description on PERL/PYTHON_PATH Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 2/6] cvsimport: allow setting a custom cvsps (2.x) program name Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 3/6] cvsimport: introduce a version-switch wrapper Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 4/6] cvsimport: start adding cvsps 3.x support Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 5/6] cvsimport: make tests reusable for cvsimport-3 Junio C Hamano
2013-01-14  7:25         ` [PATCH v2 6/6] cvsimport-3: add a sample test Junio C Hamano
2013-01-14  7:47         ` [PATCH v2 0/6] A smoother transition plan for cvsimport Jonathan Nieder
2013-01-14  7:48         ` [PATCH v2 7/6] t9600: further prepare for sharing Junio C Hamano
2013-01-14  7:52         ` [PATCH v2 8/6] t9600: adjust for new cvsimport Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v8v7wiv3a.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=chris@rorvick.com \
    --cc=esr@thyrsus.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).