8

We are currently considering the option of migrating from svn to git for all the benefits that git offers. We are currently worried about losing history and looking into the issue. We would like to know if anyone had other problems when they migrated from svn to git.

Sandah Aung
  • 6,156
  • 15
  • 56
  • 98

5 Answers5

6

There shouldn't be any problems converting from svn to git regarding losing history. That's the main purpose of revision control software anyway, to keep track of history.

The number one rule is of course: always back up your repositories before converting them and do several test runs until you feel confident enough to do it in a production environment.

A major difference is the way externals in Subversion behave compared to git submodules. See:

Also, expect to spend some time on supporting the users. Git is a different beast and some accustomed svn users can find that it is a bit unintuitive to use.

Edit: Git has built in support for importing and working with svn repositories, using git-svn.

studog
  • 992
  • 11
  • 14
Sundae
  • 724
  • 1
  • 8
  • 27
4

Git-SVN import all Subversion history (and some of additional metadata) into Git repo

git svn clone url://path/to/repo -s

-s if you have "standard" repo-layout in Subversion

but some writers recommend to use

git svn init -s http://example.com/svn/my_proj
git svn fetch

Some additional useful reading:

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • also add `git svn fetch` to loop in a script, for cloning huge repos with numerous tags and deep histories (and the occasional disconnect) – prusswan Jan 26 '12 at 10:43
4

The most problems arise when there are non-standard branches or tags in SVN. This is when someone did not copy the trunk/ folder into tags/ or branches/, but only subfolders of it. These folders appears as "ripped off" revisions without a common ancestor with trunk. But the content self is correct.

Rudi
  • 19,366
  • 3
  • 55
  • 77
2

Subversion and Git differ a lot in terms how they represent history, keep metadata, handle system specific issues. Such differences cause most of the pitfalls:

  1. Missing merge commits in Git:

    Subversion keeps information on performed merges as svn:mergeinfo property on files and directories. On conversion to Git information on sub-tree merges and cherry-picks is lost as Git has no means to represent it.

    See also After “git svn clone”, I still don't have fantastic branch-merging commit?

  2. Externals and submodules:

    Addition to @Sundae's answer: take a look at SmartGit — this tool can actually import svn:externals. It uses a file of a special format not supported by other Git clients though.

  3. Empty directories:

    Subversion treats directories as first-class citizens, Git doesn't — one has to add some placeholder file to keep a directory upon conversion. git-svn tries to handle this with external storage "unhandled log", but that works only when you keep using git-svn after the conversion.

  4. svn:ignore and .gitignore, svn:eol-style/mime-type and .gitattributes:

    git-svn does not convert Subversion properties into corresponding .gitattributes automatically. One has to run a specific command after the conversion to add attributes — anyway this information is lost upon conversion.

  5. Arbitrary Subversion properties:

    Any custom file and revision properties are lost when Subversion repository is converted to Git repository.

Have a look at SubGit. It copes well with most of the pitfalls, others are planned to be fixed in further versions.

SubGit is created to be a company-wide migration tool. One can use it as a one-shot conversion utility, but in general it is Subversion and Git continuous synchronization tool. More information you can find on its documentation page.

Community
  • 1
  • 1
vadishev
  • 2,979
  • 20
  • 28
1

I was able to migrate svn history, with branch history, to git repository using the script I wrote here:

https://github.com/onepremise/SGMS

You can support both formats:

/trunk
  /Project1
  /Project2
/branches
     /Project1
     /Project2
/tags
 /Project1
 /Project2

This scheme is also popular and supported as well:

/Project1
     /trunk
     /branches
     /tags
/Project2
     /trunk
     /branches
     /tags
Jason Huntley
  • 3,827
  • 2
  • 20
  • 27