There’s a blog post by one of the subversion developers talking about the future of subversion in a DVCS world.
I agree with parts of the post (and many of the comments) that subversion will continue to be around for a long time, but that more and more developers will start using tools like mercurial and git as a “super client” for a normal centralized version control repository.
I’ve been using mercurial in this role for the last 4 months or so and have found it invaluable.
At my company, I was recently responsible for doing an upgrade of our app from grails 1.0RC1 to a snapshot of grails 1.0.3 (every version of grails had a show-stopping bug for us so we finally decided to go with the grails trunk).
Waiting that long to upgrade caused a lot of conflicts and we’ve got one of the largest grails applications that I know of. It includes over 400 groovy files and 7 internally developed grails plugins (each of which also needs to be upgraded).
My changes touched about a quarter of the files over a 2-3 week period without my being able to check in to the main trunk of the repository once.
I found using a local mercurial repository much easier than trying to work with a cumbersome subversion branching strategy. Every time I got something working, it allowed me to make an exact snapshot of my entire grails directory. That snapshot included all of the stuff you don’t normally want to check in to svn and have in an ignore proplist (class files, jars, log files, etc). I had confidence when pulling changes down from SVN as I knew that if things got messed up, I could always
hg revert —all and get right back to the exact state I had things in before the update.
Basic steps for working with Mercurial as an SVN super-client
Once you’ve got mercurial installed (I did it through macports
sudo port install mercurial), you can just go to the root of your subversion project and create a mercurial repository (hg is the periodic table symbol for mercury):
That creates a
.hg directory in the root of your project (rather than littering the entire source tree with .svn files).
Then you can add all new files and remove any deleted files automatically with the addremove command followed by a commit:
hg addremove hg commit -m "initlal checkin of files"
Then you can modify all of the files you want to modify and run all of your tests. Before pulling down new code from subversion or checking things in, you can check it in to mercurial using:
To show you the current status of your file changes (it uses the same format as
svn status does.
You can then check any modifications in by doing
hg addremove hg commit -m "my fancy changes"
Now you know that your local file system is preserved and you confidently pull down the latest changes from svn
Without worrying that someone is going to ruin your day through a bad check-in or through an automerge gone wrong.
If you don’t like what you pulled down, you can get back to your last mercurial check-in through:
hg revert --all
Those are the basic commands that you need to know, but there are a ton of additional ones (including diff, clone, log, and grep) that are useful even in a non-branched, single node environment. This is without using any of the power that you can get when you are working in a fully DVCS environment and are pushing/pulling your changes around and branching.
Easy repository creation lets you use version control for other things
I’ve been using mercurial at home as well. My wife and I are doing some house hunting. I threw together a HTML scraping program in groovy that grabs all of the MLS house listings off a non-rss page and writes the results to a text file.
That text file is the lone file in a mercurial repository. When I pull down the latest scraped values, I can just do an
hg diff and I automatically get an updated report of all the new houses, old houses, and price changes since the last time I ran it. I can also check the history to see how long ago it appeared and what kind of price history there has been, or when houses have dropped off.
The weakness of tools like subversion is that the repository is “over there”, in a location that you don’t control and might have only period access to.
The power of a DVCS system is that the repository is wherever you want it to be and you have total control over it.