git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Julian Phillips <julian@quantumfyre.co.uk>
Cc: git@vger.kernel.org
Subject: Re: CVS -> SVN -> Git
Date: Sat, 14 Jul 2007 01:03:16 +0200	[thread overview]
Message-ID: <469804B4.1040509@alum.mit.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.0707131541140.11423@reaper.quantumfyre.co.uk>

Julian Phillips wrote:
> 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

  reply	other threads:[~2007-07-14  0:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-13 14:48 CVS -> SVN -> Git Julian Phillips
2007-07-13 23:03 ` Michael Haggerty [this message]
2007-07-14  5:30   ` Martin Langhoff
2007-07-14 17:09     ` Michael Haggerty
2007-07-14 17:32       ` Chris Shoemaker
2007-07-14 20:01         ` Michael Haggerty
2007-07-14 18:14       ` Steffen Prohaska
2007-07-15  2:22         ` Shawn O. Pearce
2007-07-14 19:52       ` Eric S. Raymond
2007-07-14 20:58         ` Junio C Hamano
2007-07-14 21:50         ` Oswald Buddenhagen
2007-07-14 22:19         ` Michael Haggerty
2007-07-14 22:44           ` Karl Fogel
2007-07-14 23:23           ` David Frech
2007-07-15  2:30             ` Shawn O. Pearce
2007-07-15 11:48             ` Michael Haggerty
2007-07-16  1:08               ` Martin Langhoff
2007-07-16  1:13                 ` Julian Phillips
2007-07-16  1:30                 ` Karl Fogel
2007-07-15  1:39           ` Eric S. Raymond
2007-07-15 12:04             ` Michael Haggerty
2007-07-15 13:36               ` Eric S. Raymond
2007-07-16  1:05             ` Martin Langhoff
2007-07-19 12:02               ` Markus Schiltknecht
2007-07-20  3:51                 ` Karl Fogel
2007-07-19 19:14               ` Simon 'corecode' Schubert
2007-07-20  8:45                 ` Markus Schiltknecht
2007-07-15 23:09       ` Scott Lamb
2007-07-19 19:18     ` Simon 'corecode' Schubert
2007-07-19 19:15 ` Simon 'corecode' Schubert
2007-07-20  5:58   ` Julian Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=469804B4.1040509@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=julian@quantumfyre.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).