Re: I have end-of-lifed cvsps

On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Although I agree with that sentence as it is stated, I also believe that the parenthesized condition rules out a _majority_ of CVS repo of non-trivial size/history. So even though a correct incremental converter could be built, it would be pretty much useless if it did not gracefully handle rewritten history. And in the face of rewritten history it becomes pretty much impossible to define what a "correct" conversion should even look like (not to mention the difficulty of actually implementing that converter...).

Here are just a couple of things a CVS user can do (and that happened fairly regularly at my previous $dayjob) that would make life difficult for an incremental converter (and that also makes stable output from a non-incremental converter hard to solve in practice):

 - A user "deletes" $file from $branch by simply removing the $branch
symbol on $file (cvs tag -B -d $branch $file). CVS stores no record of
this. Many non-incremental importers will see $file as never having
existed on $branch. An incremental importer starting from a previously
converted state, must somehow deal with that previous state no longer
existing from the POV of CVS.

 - A user moves a release tag on a few files to include a late bugfix
into an upcoming release (cvs tag -F -r $new_rev $tag $file). There
might be no single point in time where the tagged state existed in the
repo, it has become a "Frankentag". You could claim user error here,
and that such shortcuts should not happen, but that doesn't really
prevent it from ever happening. Recreating the tree state of the
Frankentag in Git is easy, but what kind of history do you construct
to lead up to that tree?

 - A modularized project develops code on HEAD, and make regular
releases of each module by tagging the files in the module dir with
"$modulename-$version". Afterwards a project-wide "stable" tag is
moved on that subset of files to include the new module release into
the "stable" tag. ("stable" is conceptually a branch, but the CVS
mechanism used here is still the tag, since CVS branches cannot
"follow" eachother like in Git). This is pretty much the same
Frankentag scenario as above, except that in this case it might be
considered Best Practice (it was at our $dayjob), and not a
shortcut/user error made by a single user.

(None of these examples even involve the "cvs admin" which allows you to do some truly scary and demented things to your CVS history...)

My point here is that people will use whatever available tools they have to solve whatever problems they are currently having. And when CVS is your tool, you will sooner or later end up with a "solution" that irrevocably rewrites your CVS history.

...Johan