MAC SVN to GIT

Atlasssian provides a wonderful tutorial on how to use their migration scripts to move your subversion code repos to their BitBucket Git Repository https://www.atlassian.com/git/tutorials/migrating-overview .

However their are a few things that all developers inevitable run into that are not explicitly documented.  I figured I would document the few things I ran into during my migration process and maybe save a few other developers a few moments.

Tip 1: Re-mounting sparseimage

I was undertaking my migration from MAC OS X (Yosemite).  Since the MAC OS is a case insensitive OS, I had to follow the instructions provided in the Atlasssian Migration guide to "Mount a case-sensitive disk image".  It worked great except of course I had to abandon my efforts and come back the next day.  Well the mount point was gone after I exited my terminal session.  The sparse image still existed. In order to remount the sparseimage I had to use the hdiutil.

cd ~
hdiutil attach ~/GitMigration.sparseimage -mountpoint ~/GitMigration


Tip 2: Extracting author information

Then as the next part of the "Preparedness" section of the migration tutorial Atlassian describes how to extract author information from your subversion repository:

java -jar  ~/svn-migration-scripts.jar authors <svn-repo> > authors.txt

Well when I tried to execute the extraction against my protected subversion repository I received the following error:

About to create the authors file.

svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option

svn: E215004: Unable to connect to a repository at URL 'http://www.foo.com/svn/repos'

svn: E215004: No more credentials or we tried too many times.

Authentication failed

Could not communicate with Subversion: check the URL of the repository, the username and the password are all valid

te

Well no where within the migration document does it indicate how to provide credentials to the scripts jar. Well take note you can pass username and password following the syntax:

$ java -jar svn-migration-scripts.jar authors
<URL> [<username> [<password>]]

Once I provided my proper credentials for the repository

java -jar  ~/svn-migration-scripts.jar authors http://www.foo.com/svn/repos fakeusername fake password > authors.txt

I was then successfully able to create the authors.txt file with the author information.

Next step according to Atlassian's migration guide was to edit the authors.txt file and change each of the usernames to the right of the equal sign to the appropriate fullname of the user/author.  I just used vi and made the modifications.

Ok preparation steps were completed.  Moving On...

Convert

The convert portion went very smoothly.  It may be a little more difficult if you didn't follow a standard svn layout.  

-- Project Name/module

   |

   -- trunk

   |

   -- branches

   |

   -- tags

Since I was working with standard, closed out projects I then just proceeded to run the conversion command

git svn clone --stdlayout --authors-file=authors.txt http://<svn-repo>/<project-location> <nameOfDirToCreate>

Note: Since Git v2.x you will want to add an option to the command above otherwise your SVN branches and tags will not properly get imported.  With Git v2.x the svn clone command implies the prefix "origin" which was empty by default in the Git 1.x.You will want to use

git svn clone --prefix="" --stdlayout --authors-file=authors.txt http://<svn-repo>/<project-location> <nameOfDirToCreate>

The process ran for a few minutes for a small project.  You may get some seemingly concerning warnings at the beginning of the progress, but they are clearly followed by warnings informing you not to be concerned as "git-svn is just searching aggressively for old history".

When the process is completed you should be left with directory as you specified in the command.

Once this is completed you are apply to explore your new Git repository.  One note is that SVN branches and tags will not appear as local branches within Git.  The Git svn clone command imports all SVN branches as remote branches, SVN tags being prefixed with tags/ .  It is indicated that this is primarily done to support two way synchronizations going forward.  Since I wasn't interested in supporting two way synchronization I just proceeded to the next step of the conversion (Clean Up). To see what will be cleaned up in the Git Repo you can run the clean up script without the -force option within the the repo directory you created.

java -Dfile.encoding=utf-8 -jar ~/svn-migration-scrips.jar clean-git

Once again this will display all the changes to be made, but will not actually apply any of them.  There wasn't any concerns with the information that was provided in the output on my particular repo and I proceeded with the --force.

Synchronize

As Atlassian indicates in their documentation it is possible to synchronize in both directions, from the new Git Repo and the SVN repo.  However they don't recommend it.  I would certainly agree to avoid the complexity, if you can.  During the transition period just use a one way sync process allowing commits to your SVN repository and follow the instructions to re-sync the changes to your new Git Repository.

In my particular cause I was just ready to cut over and start using Git.  So there was no need for continued sync steps.  

Share

So now I was ready to share out the converted repo to the distributed Git Repo (BitBucket).  You essentially need to create a bitbucket account and follow the instructions for creating a repository.

Then you will create a remote origin to your local, converted Git Repo.  The command should be run in thew root of the <nameOfDirToCreate> you created back in the convert.
  

git remote add origin https://user@bitbucket.org/user/repo_name git

Once the origin is created follow the push steps and your content should be successfully posted on BitBucket.

Migrate

Then really the migrate step consists of getting your developers to stop committing to SVN and start using Git.  The Atlassian guides do provide some nice recommendations as far as back ups and making SVN read only.  Use if you feel they are appropriate.  

Now you just need to get familiar with using Git and decide which workflow you want to standardize on for development.  Check out Atlasssian comparison of workflows.