How to migrate a complex directory structure from SVN to GIT?

Hi there,

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 .. but unfortunately sometimes I have just a trunk directory and no branches or tags directory. Sometimes the branches are in a subdirectory, sometimes in a subsubdirectory. So how can migrate my svn in an efficient way?

Thanks in advance Best wishes

-- View this message in context: http://git.661346.n2.nabble.com/How-to-migrate-a-complex-directory-structure-from-SVN-to-GIT-tp7197567p7197567.html Sent from the git mailing list archive at Nabble.com.

On 01/17/2012 08:33 PM, Asuka wrote:

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

On 2012-01-17 11:33, Asuka wrote:

 From the look of your example, each project is either a trunk, or have 
subdirectories for trunk/branches/tags so I don't think it's a problem. 
If you don't have branches or tags, just don't specify them when you 
clone your subversion repository.

If however you have a more complex layout, you can use "git svn init", then edit .git/config to suit your needs, then run "git svn fetch". And by "suit your needs", I mean you can add multiple "fetch=..." lines. In my case, I ended up having one "fetch=..." for each trunk, branch and tag. It was not efficient, it took 2 weeks to convert <30k revisions, ~200 branches/project, ~80 projects, but it works well enough for me.

	Jehan

This is why we need to breath life into the git-remote-svn effort. We should be able to handle imports of that size in minutes. (Cost of dumping from SVN aside.)

-- David Barr