On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> A correct incremental converter could be done (as long as the CVS users
> don't literally change history retroactively) but it would be a lot of work.
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
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html