This process worked for me. I take no responsibility for any damage or loss incurred as a result of following or not following these steps or, for that matter, anything else you might do or not do.
- SVN is hosted at
svn.domain.com.au. - SVN is accessible via
http(other protocols should work). - GitLab is hosted at
git.domain.com.auand:- A group is created with the namespace
dev-team. - At least one user account is created, added to the group, and has an SSH key for the account being used for the migration (test using
ssh git@git.domain.com.au). - The project
favourite-projectis created in thedev-teamnamespace.
- A group is created with the namespace
- The file
users.txtcontains the relevant user details, one user per line, of the formusername = First Last <address@domain.com.au>, whereusernameis the username given in SVN logs. (See first link in References section for details, in particular answer by user Casey).
- subversion version 1.6.17 (r1128011)
- git version 1.9.1
- GitLab version 7.2.1 ff1633f
- Ubuntu server 14.04
git svn clone --stdlayout --no-metadata -A users.txt http://svn.domain.com.au/svn/repository/favourite-project
cd favourite-project
git remote add gitlab git@git.domain.com.au:dev-team/favourite-project.git
git push --set-upstream gitlab masterThat's it! Reload the project page in GitLab web UI and you will see all commits and files now listed.
- If there are unknown users, the
git svn clonecommand will stop, in which case, updateusers.txt,cd favourite-projectandgit svn fetchwill continue from where it stopped. - The standard
trunk-tags-brancheslayout for SVN repository is required. - The SVN URL given to the
git svn clonecommand stops at the level immediately abovetrunk/,tags/andbranches/. - The
git svn clonecommand produces a lot of output, including some warnings at the top; I ignored the warnings.
- http://stackoverflow.com/questions/79165/migrate-svn-repository-with-history-to-a-new-git-repository/3972103
- https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/import.md (this method didn't work for me)
- https://github.com/gitlabhq/gitlabhq/issues/4137 (describes why the above didn't work)
- https://github.com/gitlabhq/gitlab-shell/issues/32
@cbscd The
users.txtfile should contain an entry for all of the users mentioned in the SVN history. It doesn't matter whether the user is currently able to access the repository, all that matters is that they are listed in the history. If there is a user in the SVN history that isn't represented in theusers.txtfile, the process will fail, but you can update theusers.txtfile with the missing user and start again.