Re: I have end-of-lifed cvsps

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Dec 12, 2013, 13:42 UTC
Message-ID: <CACPiFC+bopf32cgDcQcVpL5vW=3KxmSP8Oh1see4KduQ1BNcPw@mail.gmail.com>
In-Reply-To: <20131212042624.GB8909@thyrsus.com>

On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> You'll have to remind me what you mean by "incremental" here. Possibly
> it's something cvs-fast-export could support.

User can

 - run a cvs to git import at time T, resulting in repo G
 - make commits to cvs repo
 - run cvs to git import at time T1, pointed to G, and the import tool
will only add the new commits found in cvs between T and T1.

> But what I'm trying to tell you is that, even after I've done a dozen
> releases and fixed the worst problems I could find, cvsps is far too
> likely to mangle anything that passes through it.  The idea that you
> are preserving *anything* valuable by sticking with it is a mirage.

The bugs that lead to a mangled history are real. I acknowledge and respect that.

However, with those limitations, the incremental feature has value in many scenarios.

The two main ones are as follows:

 - A developer is tracking his/her own patches on top of a CVS-based
project with git. This is often done with git-svn for example. If
old/convoluted branches in the far past are mangled, this user won't
care; as long as HEAD->master and/or the current/recent branch are
consistent with reality, the tool fits a need.

 - A project plans to transition to git gradually. Experienced
developers who'd normally work on CVS HEAD start working on git (and
landing their work on CVS afterwards). Old/mangled branches and tags
are of little interest, the big value is CVS HEAD (which is linear)
and possibly recent release/stable branches. The history captured is
good enough for git blame/log/pickaxe along the "master" line. At
transition time the original CVS repo can be kept around in readonly
mode, so people can still checkout the exact contents of an old branch
or tag for example (assuming no destructive "surgery" was done in the
CVS repo).

The above examples assume that the CVS repos have used "flying fish" approach in the "interesting" (i.e.: recent) parts of their history.

[ Simplifying a bit for non-CVS-geeks -- flying fish is using CVS HEAD for your development, plus 'feature branches' that get landed, plus long-lived 'stable release' branches. Most CVS projects in modern times use flying fish, which is a lot like what the git project uses in its own repo, but tuned to CVS's strengths (interesting commits linearized in CVS HEAD).

Other approaches ('dovetail') tend to end up with unworkable messes given CVS's weaknesses. ]

The cvsimport+cvsps combo does a reasonable (though imperfect) job on 'flying fish' CVS histories _and that is what most projects evolved to use_. If other cvs import tools can handle crazy histories, hats off to them. But careful with knifing cvsps!

cheers,

-- 
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff