git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Asuka <c.bauers@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: How to migrate a complex directory structure from SVN to GIT?
Date: Wed, 18 Jan 2012 11:43:48 +0100	[thread overview]
Message-ID: <4F16A264.9030503@alum.mit.edu> (raw)
In-Reply-To: <1326828837924-7197567.post@n2.nabble.com>

On 01/17/2012 08:33 PM, Asuka wrote:
> I would like to migrate my svn repository to git. The structure looks like
> the following:
> 
> svn
>    |_Project1
>          |_subproject1
>                |_branches
>                       |_branch1
>                       |_branch2
>                |_trunk
>                |_tags
>                       |_tagv1
>    |_Non-JavaProject
>          |_subproject
>    |_Project2
>           |_AnotherSubproject
>                |_SubSubproject
>           |_Subproject2
>                |_branches
>                |_tags
>           |_Subproject3
>                |_trunk
>           |_Subproject4
>                |_Subsubproject
>                        |_branches
>                        |_tags
>                        |_trunk
> 
> I would like to migrate all branches and tags

This can be confusing because Subversion confounds the namespace for
lines of development (trunk, branches, and tags) with those of filename
paths.  The basic rule is: normally each trunk/branches/tag triplet
corresponds to a single project, and each project should be converted
into a separate git repository.

In your case it is hard to tell where the project boundaries are without
more information.

If some projects don't have branches or tags, that is OK; you can
configure git-svn pretty flexibly.

If some have branches and/or tags but not trunk, give it a try; I'm not
sure whether git-svn can handle it.

If some subprojects (including their trunk/branches/tags directories)
are nested within the source code of the enclosing projects (thus
entangling the namespaces), then you have chaos even in the Subversion
world.  Such a mess can probably also be rescued, but it will be more
involved.  For example, you might use svndumpfilter to strip
improperly-nested projects out of (copies of) your Subversion repository
*before* converting the enclosing project, or play some kind of
git-filter-branch tricks *after* the conversion.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2012-01-18 10:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17 19:33 How to migrate a complex directory structure from SVN to GIT? Asuka
2012-01-18 10:43 ` Michael Haggerty [this message]
2012-01-18 18:47 ` Jehan Bing
2012-01-27  4:46   ` David Barr

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=4F16A264.9030503@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=c.bauers@gmx.de \
    --cc=git@vger.kernel.org \
    /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).