Heads up, an emergency fix for git-cvsimport is coming shortly

Bad news: the combination of cvsps and the existing git-cvsimport script is seriously broken in both places. This morning I fixed a nasty bug in cvsps's branch detection and shipped 3.3. This is a different bug from the broken (and now removed) ancestry-branch tracking.

Good news: I have fixed all the urgent bugs (and now you know how I spent my holidays). Somewhat to my surprise, half the problems listed on the git-cvsimport manual page turned out to be problems in git-cvsimport itself, not more cvsps lossage. Those bugs are dead.

cvsps is now much better about warning when it cannot translate a tag or sees a dubious branch structure. I've also enhanced git-cvsimport to have an engine switch so it can optionally use cvs2git as its conversion engine. If and when I can get parsecvs back into working shape, I will add it to the set of supported engines.

I have a test suite that proves fixes for all the urgent problems, but that needs a bit more work before I'm willing to call it done.

In a few days I will ship a patch that replaces git-cvsimport with a working version and removes the t960[123] tests from the git tree. Those are not actually tests of git-cvsimport itself but of the underlying conversion engine, and now form about half of cvsps's own regression-test suite.

On Sun, Dec 30, 2012 at 1:21 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

I tried the new version and found I'm unable to import via pserver:

  $ ./cvsps --root :pserver:me@localhost:/cvsroot module
  cvsps: connect error: Connection refused
  cvsps: can't get CVS log data: Connection refused

Running 2.2b1 (the version packaged w/ Fedora 17) with the same
arguments with the addition of --cvs-direct connects OK.  I haven't
taken much time to look into this, so I might be doing something dumb.
 Thought I'd find out if this is a known issue before delving into it.

Also, I'm curious what impact removing the caching from cvsps will have on incremental imports. Is there any?

Thanks,

Chris Rorvick

Chris Rorvick <chris@rorvick.com>:

Your problem does reproduce here. This paragraph from the output of 'aptitude show cvs' may be relevant:

 This package contains a CVS binary which can act as both client and server,
 although there is no CVS dæmon; to access remote repositories, please use
 :extssh: not :pserver: any more.

It's therefore possible there's something slightly busted about the pserver method at the CVS end, and the 3.[23] code trips over it even though the old code did not. Note that new cvsps uses cvs-direct mode all the time; the old support for fetching logs through local CVS commands is gone.

I use 

      cvsps --root :local:$PWD/repo module

for my testing, and that works. I'm up to my ears in finishing up the test suite and tracking bugs in the repo-analysis code; if you want to speed the process up, try running a :pserver: fetch with -v on under both old and new code to see how the protocol transactions differ.

Not that I know of. The caching was a performance hack for human viewing of changesets.