John Keeping [off-list ref] writes:
On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:
quoted
* jc/cvsimport-upgrade (2013-01-14) 8 commits
- t9600: adjust for new cvsimport
- t9600: further prepare for sharing
- cvsimport-3: add a sample test
- cvsimport: make tests reusable for cvsimport-3
- cvsimport: start adding cvsps 3.x support
- cvsimport: introduce a version-switch wrapper
- cvsimport: allow setting a custom cvsps (2.x) program name
- Makefile: add description on PERL/PYTHON_PATH
The most important part of this series is the addition of the new
cvsimport by Eric Raymond that works with cvsps 3.x. Given some
distros have inertia to be conservative, Git with cvsimport that
does not work with both 3.x will block adoption of cvsps 3.x by
them, and shipping Git with cvsimport that does not work with cvsps
2.x will block such a version of Git, so we'll do the proven "both
old and new are available, but we aim to deprecate and remove the
old one in due time" strategy that we used successfully in the
past.
Will merge to 'next'.
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.
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.
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?
On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
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 [1] indicates that he won't do any more
work on git-cvsimport.
[1] http://article.gmane.org/gmane.comp.version-control.git/214057
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
output:
from: refs/heads/branch^0
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
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -18,6 +18,11 @@ SYNOPSIS
DESCRIPTION
-----------
+*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< --
John
On Wed, Jan 23, 2013 at 3:28 AM, John Keeping [off-list ref] wrote:
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.
Do you really need a timestamp per branch, though? If you have
branches A and B, and B has a commit timestamp 5 minutes after A, you
can infer that nothing happened on A for those five minutes, right?
So maybe a single timestamp is sufficient, it just may not be picking
the right one. Instead cvsimport-3 should compute the latest
timestamp across all import branches.
Chris
On Wed, Jan 23, 2013 at 07:26:24AM -0600, Chris Rorvick wrote:
On Wed, Jan 23, 2013 at 3:28 AM, John Keeping [off-list ref] wrote:
quoted
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.
Do you really need a timestamp per branch, though? If you have
branches A and B, and B has a commit timestamp 5 minutes after A, you
can infer that nothing happened on A for those five minutes, right?
So maybe a single timestamp is sufficient, it just may not be picking
the right one. Instead cvsimport-3 should compute the latest
timestamp across all import branches.
The problem is telling which is an import branch, since it currently
just used "refs/heads/<branch>".
I do have a change to write the timestamp to a file, which takes the
newest commit across all of the branches that have changed during an
import. That may well be good enough but doesn't let you incrementally
update a repository that has been cloned from elsewhere.
John