A couple of weeks ago we shut down the Crowd Favorite office for a day and a half to do a migration from SVN to Git. This was not a small undertaking. We had nearly five years of code in a single SVN repository that was then broken out into literally hundreds of Git repositories.
The main reason for the change is to be able to support a branch driven development workflow (using Git Flow). We were already using this for newer projects (including some of our Open Source WordPress plugins that we host on GitHub), and we were seeing lots of areas where this approach would be a big improvement to our SVN workflows. We think it will especially pay dividends for our ongoing retainer clients.
With our ongoing clients we are commonly engaged in building new features and functionality while also needing to be able to make smaller changes (hotfixes) that are pushed up immediately. With Git it is easy for us to maintain development of more involved functionality in feature branches and still being able to push up quick changes as needed.
We’ve been following a modular development methodology for years, so we have a large number of libraries, plugins, etc. that are shared across various projects. Converting these from SVN externals to Git submodules was a good bit of busy work, but more importantly it required everyone to get comfortable with the difference between SVN externals and Git submodules. The biggest changes are that the submodules default to a detached head and don’t auto-update to the latest code in a branch. These are generally positives, but require changes to how you think about things. More on this in a future post.
We are using GitHub to host our Open Source projects, but we choose to host our own Git server for our private repositories. We are using Gitolite for repository management, GitPHP to provide a hackable web interface and we’re planning to use Gerrit for code reviews.
One of the other challenges was setting up a repository structure that we were happy with for our WordPress sites. We settled on the following:
/index.php
/local-config.php
(unversioned – has machine specific settings)
/wp-config.php
(define WP_CONTENT_DIR and WP_CONTENT_URL here)
/wp/
(WordPress core as a shallow Git submodule or SVN checkout)
/wp-content/
(plugins, themes, etc.)
This works quite nicely for simple and painless WordPress core upgrades, local development environments, and scriptable deployments. With a standardized structure, we’re also able to create scripts to automate the creation and data seeding of local development environments. We’re still working on the local dev set-up script, but I’m really excited about it. It should make it much easier for any developer on our team to quickly spin up a project and be able to contribute to it.
Does this sound like fun? We’re hiring! Come help us define and implement best practices that make developers effective; and work on interesting and challenging projects.
This post is part of the thread: Version Control – an ongoing story on this site. View the thread timeline for more context on this post.
Alex King: SVN to Git Migration: A couple of weeks ago we shut down the Crowd Favorite office for a day and a ha… http://t.co/grSH0CsA
[…] You are here: Home > Links > Crowd Favorite takes a day, switches from SVN to Git PermalinkCrowd Favorite takes a day, switches from SVN to GitBy Ryan Imel 1 min agoFebruary 14, 20120 var addthis_product=’wpp-263′;var […]
Alex King: SVN to Git Migration http://t.co/rXEsDduB
Alex King: SVN to Git Migration – A couple of weeks ago we shut down the Crowd Favorite office for a day and a half … http://t.co/Yae0tB1Q
[…] King’s blog post explains their thought process, and a bit about their new […]
SVN to Git Migration : http://t.co/5X3MEIVA http://t.co/MSdJfSBf
Alex King explains how and why they migrated from SVN to Git http://t.co/Mf5KzpMC #tech
SVN to Git Migration http://t.co/aHXIk04c
I’ve been running my clients WP sites with this structure for some time and it really ease the Git management process. The only con is that many plugins are not so-well developed and doesn’t use ABSPATH or WP_CONTENT_DIR to recover their resources. If you’ve got any idea on managing these …
We maintain mirrors of most plugins we use in our GitHub account. This is mainly so we can set up submodules for them, but we can also make modifications there if needed.
@zakimahomed RT @curtismchale: SVN to Git Migration : http://t.co/fNfngYJZ http://t.co/m2NckGnC
Alex King about their recent SVN to Git Migration http://t.co/VzhphygE
RT @kovshenin: Alex King explains how and why they migrated from SVN to Git http://t.co/8EMX8Kaa #tech @cappydavis
New on @alexkingorg: SVN to Git Migration http://t.co/ZIHhIhUV
Interesting read. RT @alexkingorg: Some notes from our migration from SVN to Git. http://t.co/YGvo0Wj0
Devs: Must-read – @alexkingorg’s SVN to Git Migration – http://t.co/ysPzl9ON See git-flow piece specifically.
There is a tool to simplify the migration. Have a look at http://subgit.com/
1. It imports all the SVN data into Git.
2. Enables both SVN and Git access to the same history and the same data. So, you can send changes with any SVN or Git client keeping all things synchronized.
You could install subgit into your repository, adjust Git repositories as needed and drop SVN by uninstalling subgit. And all that with no blocking on 1,5 days. Too bad it’s too late 🙂
Looks like an interesting tool, but this does the opposite of what we were trying to accomplish.
[…] A couple of weeks ago we shut down the Crowd Favorite office for a day and a half to do a migration from SVN to Git. This was not a small… Read More […]
[…] part of our move to Git, we now host our WordPress code on GitHub. Carrington Core was moved over a while ago and I finally […]
[…] you’re a serious Open Source developer in 2012, you’re using Git. Crowd Favorite made the move as a team back in February. No regrets. More and more of the WordPress community is joining us in […]
SVN was good, git is great, moving is well worth it QT @cmsreport: SVN to Git Migration http://t.co/o3ccxigu