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:
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/
On 2012-01-17 11:33, Asuka wrote:
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?
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
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