On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote:
> John Keeping <j...@keeping.me.uk> writes:
>> Would you mind holding off on this? As it stands there are a couple of
>> issues with the cvsimport-3 script including: ...
> Actually I do. I think this, at least the early part of it, should
> be merged to 'next' as soon as possible, *unless*
> (1) The cvsimport-2 & cvsps2 combo this series ships gives worse
> experience than cvsimport we ship in v1.8.1 to end users of the
> current cvsimport with cvsps2; and/or
> (2) The cvsimport-3 in this series, which is a copy of an older
> version of what Eric has, is so broken that we are better off
> starting cvsimport-3 by getting a fresh copy from Eric which
> has been rewritten in a major way, than applying huge
> incremental update patches that amounts to a total rewrite.
> The point (1) is important from "no regression" point of view, and
> in a sense more important between the two because it is the first
> step in the overall transition plan.
> Even though there may be remaining issues in cvsimport-3 and cvsps3
> (what new piece of software don't have issues?), my limited
> observation of the exchanges between you and Eric suggests me that
> the problem is not something that requires a total rewrite of how
> cvsimport-3 works, so I do not expect the point (2) to be true,
> either, but if I am mistaken, please let me know.
ESR's cvsimport.py in the cvsps repository has no fixes over what's
here. I think his comment in  indicates that he won't do any more
work on git-cvsimport.
In my opinion the incremental import support really is substantially
worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output
of git-for-each-ref to calculate the dates from which to continue each
branch. cvsps cannot be told this information and so the cvsimport-3
script just takes the date of the last commit on the current branch.
On top of that, the incremental switch to cvsps-3 just causes it to
on the first commit for each branch, which I can't see working if a new
branch is created in CVS.
> By advancing the topic to 'next', we will give people a more solid
> (read: not getting rewound) foundation to work with than "if you are
> really interested, grab the tip of 'pu', replace it with even newer
> copy from Eric's repository and try it out", so that more people can
> help us polish the scaffolding to let us ship two versions and also
> find issues in the new cvsimport-3 and help fixing them. At least,
> that is what I've been hoping.
That's what I've done and it's convinced me that cvsps-3 is not ready
for use with incremental imports as it stands.
> I could stop at the first three patches, that is, introducing the
> version switch wrapper that switches between cvsps2+cvsimport-2
> combo and nothing, and then let you and Eric redo the "start adding
> cvsps 3.x support" and later patches when cvsimport-3 is ready.
> That would give you a larger lattitude to rework cvsimport-3. Is
> that preferrable?
My preference would be for something like this, possibly with an
expanded examples section showing how to pipe the output of cvsps-3 or
cvs2git into git-fast-import:
-- >8 --
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 9d5353e..20b846e 100644
@@ -18,6 +18,11 @@ SYNOPSIS
+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
+deprecated; it does not work with cvsps version 3 and later. If you are
+performing a one-shot import of a CVS repository consider using cvsps-3,
+cvs2git or parsecvs directly.
Imports a CVS repository into git. It will either create a new
repository, or incrementally import into an existing one.
-- 8< --
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