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

Re: CVS -> SVN -> Git

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jul 13, 2007, 23:03 UTC
Message-ID
<469804B4.1040509@alum.mit.edu>
In-Reply-To
<Pine.LNX.4.64.0707131541140.11423@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
Show 8 quoted lines
> Has anyone managed to succssfully import a Subversion repository that
> was initially imported from CVS using cvs2svn using fast-import?
> 
> It looks like cvs2svn has created a rather big mess.   It has created
> single commits that change files in more than one branch and/or tag. It
> also creates tags using more than one commit.  Now I come to try and
> import the Subversion history into git and I'm having trouble creating a
> sensible stream to feed into fast-import.

I'm the main cvs2svn developer. Obviously, the tool is intended to convert to Subversion, but there are ways to tune it to make its output a little bit more git-friendly.

[Please note that both CVS and SVN allow changes to multiple tags/branches in a single commit and creating tags using more than one commit. That is why cvs2svn converts these repository "features" 1:1 by default.]

Release 2.0.0-rc1 of cvs2svn (released today) has a --no-cross-branch-commits option that prevents commits that affect more than one branch. For multiproject conversions, the "ctx.cross_project_commits" option might also be useful. (The latter is only available if you start cvs2svn with an --options file.)

The new cvs2svn release is also more intelligent about determining the most likely source branch from which a tag/branch was created. This does not eliminate the creation of tags from more than one revision, but it should reduce its frequency. If your repository uses any vendor branches, you might also consider --exclude'ing them. In the new cvs2svn version, this causes vendor revisions to be grafted onto trunk and thereby eliminates another common cause of multiple-source branches/tags.

Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about what it would take to write some other back ends for cvs2svn--turning it, essentially, into cvs2xxx. Most of the work that cvs2svn does is inferring the most plausible history of the repository from CVS's sketchy, incomplete, idiomatic, and often corrupt data. This work should also be useful for a cvs2git or cvs2hg or cvs2baz or ...

I haven't played with a distributed SCM yet, but if somebody would be interested in working with me on this please let me know.

Michael
Previous: Julian PhillipsNext: Martin Langhoff
Message 2 of 31 in “CVS -> SVN -> Git”
  1. Julian PhillipsJul 13, 2007
  2. Michael HaggertyJul 13, 2007
  3. Martin LanghoffJul 14, 2007
  4. Michael HaggertyJul 14, 2007
  5. Chris ShoemakerJul 14, 2007
  6. Michael HaggertyJul 14, 2007
  7. Steffen ProhaskaJul 14, 2007
  8. Shawn O. PearceJul 15, 2007
  9. Eric S. RaymondJul 14, 2007
  10. Junio C HamanoJul 14, 2007
  11. Oswald BuddenhagenJul 14, 2007
  12. Michael HaggertyJul 14, 2007
  13. Karl FogelJul 14, 2007
  14. David FrechJul 14, 2007
  15. Shawn O. PearceJul 15, 2007
  16. Michael HaggertyJul 15, 2007
  17. Martin LanghoffJul 16, 2007
  18. Julian PhillipsJul 16, 2007
  19. Karl FogelJul 16, 2007
  20. Eric S. RaymondJul 15, 2007
  21. Michael HaggertyJul 15, 2007
  22. Eric S. RaymondJul 15, 2007
  23. Martin LanghoffJul 16, 2007
  24. Markus SchiltknechtJul 19, 2007
  25. Karl FogelJul 20, 2007
  26. Simon 'corecode' SchubertJul 19, 2007
  27. Markus SchiltknechtJul 20, 2007
  28. Scott LambJul 15, 2007
  29. Simon 'corecode' SchubertJul 19, 2007
  30. Simon 'corecode' SchubertJul 19, 2007
  31. Julian PhillipsJul 20, 2007

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.