You’re still using SVN!?
Jim Blandy trembles as he watches Linus tempt you to come closer. Linus throws his VCS at you with horrible puns such as: ‘Git closer my boy’ and ‘In Git We Trust’. He appears angelic while you are wondering why Jim ever captivated you in the first place. Maybe it was the SVN charm?
You start forgetting the SVN commands. Worse, you start confusing Git commands with SVN when talking to friends. No longer will you be the only person answering yes to, “Does anyone use SVN?”. As soon you are done migrating to Git you will be denouncing SVN. You are starting to smile now and begin to think of ways to act like you’ve always ‘Gitted’ before. SVN? What is that!?
Your smirk drops.
It dawns on you that you have to migrate your code repositories first and you have no idea on how to start.
SVN to Git
I was tasked with migrating our SVN repositories to Git. Originally the idea was to cut ties and loose the history. We decided it is important to maintain history if possible. The first step was identifying our repositories and our svn-externals in the repositories.
First up was gathering the SVN authors. Your mileage may vary and you might find a more useful command but in general you need the svn author’s to map to Git authors. I recommend using a public email address for the Git author just so it is easier when looking at history – especially if using a hosted solution.
cloned did a ‘git svn’ clone on our main product’s repo. This command was done on the repo itself and not trunk or a branch. This is needed to maintain all the history if you choose to do so.
Next, it is time to clean the repo. Technically it should only be done in ‘edge’ cases and for our case – we needed it because we wanted a clean break. After this you can perform git branch or git tag and see the old svn branches and tags. Pay special attention to the “Clean the new Git repository” part!
Now the fun! Set your remote up with `git remote add origin <github|bitbucket|gitlab>` and try a `git push origin –all`. Did it work!? Did it push everything! It did in my case – and now we are one step closer.
What about those pesky svn:externals?
There is no way, that I know of, to convert svn:externals to a git submodule or something else by hand. We decided on using Composer for many reasons. The main points are: easier to manage semantic versions of dependencies, large user base, open source, and our internal dependencies already leveraged Composer.
I had to convert them over by hand. It wasn’t really hard at all though since our svn:externals file pointed the dependencies to /vendor anyway.
What is next?
Right now I am working on the build process to get PHING to use Git. Shouldn’t be too hard. The longest part of this process is waiting for the five plus years of code to download from SVN. The next challenge was getting the repositories prepped and fixed so we didn’t have failing tests. I’ll save that for another post.
What do you think?
I’d be interested to hear your feedback in the comments below! Has your conversion been a nightmare or a dream? What struggles did you have? Thanks!
Quick references I found useful: