2

Let's suppose we have a subversion repository which looks like

/original/0.1
/original/0.2
/variantA/trunk
/variantA/branches/who/branch_for_xxx
/variantA/branches/she/branch_for_yyy
/variantB/trunk
/variantB/branches/who/branch_for_zzz
(... 30 or 40 alike)

where variantA and variantB are forks of the original software.

I am looking for a method for migrating this repository into a distributed version control system: a method

  • not necessarily wigh a single command
  • for any one of well-known distributed version control systems
  • making the dvcs think of them branches: /official/{0.1,0.2} trees, /variantA/trunk tree, ...
  • making the dvcs aware of the inheritance relation of those trees
yhirai
  • 131
  • 3

4 Answers4

3

Mercurial comes with a convert extension which should do what you want. See the convert extension details on the Mercurial web site.

Dickon Reed
  • 3,575
  • 4
  • 23
  • 25
2

For Git, see the instructions at http://github.com/guides/import-from-subversion

The last time that I did it manually, I used the commands below. (This was for a project which did not use tags or branches. Using svn2git might produce better results than git-svn if you have tags or branches.)

cat "mysvnusername = Me Myself <me.myself@somewhere.com>" >> authors.txt

svnserve --daemon --foreground --root <SVN-REPO-PARENT-DIR>
git svn clone --stdlayout --authors-file=authors.txt --no-metadata svn://localhost/<SVN-REPO-NAME>

# push to a public repo and clone from there, to get push/pull working easily
cd <SVN-REPO-NAME>
git remote add origin git@github.com:mygithubusername/<GIT-REPO-NAME>.git
git push origin master
cd ..
rm -rf <SVN-REPO-NAME>

git clone git@github.com:mygithubusername/<GIT-REPO-NAME>.git

But since you have a non-standard SVN repository layout, you will need to specify the --trunk, --tags and --branches parameters instead of --stdlayout for git svn clone.

To represent the whole inheritance history of your repository, you could try reordering your repository so that instead of a non-standard hierarchy you would have a standard flat repository layout:

/branches/original-0.1
/branches/original-0.2
/branches/variantA-trunk
/branches/variantA-who-branch_for_xxx
/branches/variantA-she-branch_for_yyy
/branches/variantB-trunk
/branches/variantB-who-branch_for_zzz
...

That should make it easier for import tools to understand the repository. Then when they have been imported, you can reorganize them better inside the new repository.

Also, I've heard that Git 1.6.x supports deep cloning, so that you can give to git svn clone parameters such as --branches=branches/*/* which will look deep into the hierarchy for branches. See this post for an example of using it.

Community
  • 1
  • 1
Esko Luontola
  • 73,184
  • 17
  • 117
  • 128
  • 1
    +1. Good post with much more practical details than my own answer – VonC May 09 '09 at 12:42
  • I did recently some SVN-to-Git conversions and with some projects patches were helpful in fixing the history. I wrote about it in my blog: http://blog.orfjackal.net/2009/05/converting-confused-svn-repositories-to.html – Esko Luontola May 09 '09 at 17:53
0

If you consider Git as a possible DVCS candidate, the ruby script svn2git does what you need.

More details in the question: Cloning a Non-Standard Svn Repository with Git-Svn

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

$ bzr svn-import --layout trunk1 svn-root-url bzr.repo

Should do the right thing. You need to have the bzr-svn plugin installed in order to be able to do this.

user103684
  • 9
  • 1