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