"Eric S. Raymond" <e...@thyrsus.com> writes:
> The combination of git-cvsimport and cvsps had serious problems.
> Among these were:
> (1) Analysis of branchy repos was buggy in multiple ways in both
> programs, leading to incorrect repo translations.
> (2) Even after a correct branch analysis, extra (redundant) fileops
> would often be generated on the new-branch side.
> (3) Inability to report more than one tag pointing to the same revision.
> (4) Failure in certain cases of clock-skew reported by the t9603 test.
> (5) Failure to use commitids for changeset ordering in cases were this
> would have prevented clock skew from causing incorrect grouping.
> Problems 2-5 and portions of problem 1 have been solved by a major
> rewrite of cvsps (the 3.x release series); it now emits a git
> fast-import stream.
So..., is this a flag-day patch?
After this is merged, users who have been interoperating with CVS
repositories with the older cvsps have to install the updated cvsps
before using a new version of Git that ships with it? As long as
they update both cvsps and cvsimport, they can continue using the
existing repository to get updates from the same upstream CVS
repository without losing hisory continuity?
I would have preferred an addition of "git cvsimport-new" (or rename
of the existing one to "git cvsimport-old"), with additional tests
that compare the results of these two implemenations on simple CVS
history that cvsimport-old did *not* screw up, to ensure that (1)
people with existing set-up can choose to keep using the old one,
perhaps by tweaking their process to use cvsimport-old, and (2) the
updated one will give these people the identical conversion results,
as long as the history they have been interacting with do not have
the corner cases that trigger bugs in older cvsps.
Or am I being too conservative?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html