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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html