git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 1, 2013, 21:54 UTC
Message-ID
<7vfw2k8t7k.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20130101172645.GA5506@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
Show 19 quoted lines
> 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?
Previous: Eric S. RaymondNext: Eric S. Raymond
Message 2 of 24 in “Replace git-cvsimport with a rewrite that fixes major bugs.”
  1. Replace git-cvsimport with a rewrite that fixes major bugs.Eric S. Raymond, Jan 1, 2013
  2. Junio C HamanoJan 1, 2013
  3. Eric S. RaymondJan 2, 2013
  4. Junio C HamanoJan 2, 2013
  5. Jonathan NiederJan 2, 2013
  6. Eric S. RaymondJan 2, 2013
  7. Jonathan NiederJan 2, 2013
  8. Eric S. RaymondJan 2, 2013
  9. Martin LanghoffJan 2, 2013
  10. Eric S. RaymondJan 2, 2013
  11. Thomas BergJan 2, 2013
  12. Martin LanghoffJan 2, 2013
  13. Eric S. RaymondJan 2, 2013
  14. Martin LanghoffJan 2, 2013
  15. Jonathan NiederJan 2, 2013
  16. Andreas SchwabJan 2, 2013
  17. Junio C HamanoJan 2, 2013
  18. Eric S. RaymondJan 2, 2013
  19. Junio C HamanoJan 2, 2013
  20. Chris RorvickJan 3, 2013
  21. Junio C HamanoJan 3, 2013
  22. Antoine PelisseJan 3, 2013
  23. Junio C HamanoJan 3, 2013
  24. Michael HaggertyJan 3, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.