"Eric S. Raymond" <esr@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html