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

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

[Eric S. Raymond]

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

It is proper to take alarm at the first experiment on our
liberties. We hold this prudent jealousy to be the first duty of
citizens and one of the noblest characteristics of the late
Revolution. The freemen of America did not wait till usurped power had
strengthened itself by exercise and entangled the question in
precedents. They saw all the consequences in the principle, and they
avoided the consequences by denying the principle. We revere this
lesson too much ... to forget it	-- James Madison.

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

[Chris Rorvick]

On Sun, Dec 30, 2012 at 1:21 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 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.

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

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

[Eric S. Raymond]

Chris Rorvick <chris@rorvick.com>:
> 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.

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.

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

Not that I know of.  The caching was a performance hack for human viewing
of changesets.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>