I have been using SVN for years, basically since 2004, when I got really fed up with CVS, which was used at my work back then. What seduced me in SVN was the ability to easily configure it as an Apache module, coupled with our central LDAP authentication, and SSL encryption, and its ability to track file renames/moves.
I also enjoy its wide platform compatibility, as well as its excellent windows companion tool : TortoiseSVN, which works wonders compared to the horrible WinCVS.
It took me a little bit of time to fully understand the benefit of atomic commit numbers, as opposed to file versions in CVS, as well as the directory structure used to simulate branches and tags (seems like implemented as an afterthought, doesn’t it ?).
Then came the DCVS.
I first learned about Mercurial. I was impressed by its great merging and branches abilities, more than the whole “distributed” concept, however I found it a bit tricky to install and make it work in Windows, especially with TortoiseHg, which was definitly not yet as good as its older brother, TortoiseSVN. So I didn’t look further, and stuck with SVN for the time being.
A few years later
I’m now working in an environment where rapid website release cycles mean that a lot of developments/commits make it directly to production, the production environment being directly based on the current trunk, probably a wrong approach, but most developers in the team don’t care about branches.
This means that if someone is working on a feature that hasn’t been completed and spans several commits on the trunk, any urgent bugfix will cause these features to go online, and inevitably cause bugs on the production website.
The obvious solution to this problem is feature branches, branches that only live for as long as the feature is not complete, and get reintegrated into the trunk when functional and tested.
However, in SVN, every branch is server-side, which means that the central repository might become really encumbered with trash in the /branches directory, unless each developer deletes such a branch when done with it. Guess what ? In practice, a lot of orphan branches remain, and noone cares about deleting them.
Of course, this has an interest because SVN also works as a code backup platform, so at the end of the day, each developer should put his code on the well-protected server, instead of keeping it on their potentially dead-the-next-day desktop computer.
Also consider the fact that developers can work from home as well as from the office, and potentially need their code from anywhere.
SVN has also another flaw, it’s really getting slow when working on large codebase, especially with binary files like images, quite common in websites.
This is caused by the fact that everything happens between the client and the server, even getting file or repository-wide history. Trying to work out a problematic trail of changes is basically impossible if the internet connection is down for some reason.
Here comes a new challenger
That’s why I got very interested when I tried Git, which I had been following since its introduction by Linus Torvald, after the infamous issue with Bitkeeper.
Git’s Windows support has evolved quite a bit since the early days, and I must say that TortoiseGit (a TortoiseSVN clone) has become a quite good piece of software, allowing people to more easily bypass the initial steep learning curve of the many many git commands and options, by using a simple yet potent and familiar UI.
Git solves practically every issue I have encountered so far, especially about branches. Feature branches are a core part of Git’s workflow, and they’re freaking fast.
It also makes working locally very practical, as apart from the initial cloning, and eventual pull/pushes, everything is done on the client side.
And at least branches and tags are properly implemented without feeling “half-baked”.
Now you might certainly ask me: “how can it be used in a server-is-the-backup environment if all is done in a distributed way ?”
Very simply of course. As long as a developer has access to a machine via SSH and that has git installed, saving your work is just a matter of creating a bare repository in your account, and add it locally as a remote into which you can push and pull at will, without ever needing to communicate with the “central” repository.
Goodbye, really ?
At work, no, we’re not quite ready for the switch yet, but it will come, eventually.
I’m talking about flvmeta, instead.
When I decided to host flvmeta publicly back in 2007, I decided to choose Google Code project hosting, because of its simplicity, and its support of SVN. It’s been a good choice, and has worked flawlessly since then, with an active community, bug reports, and a now established codebase (says ohloh.net).
These days, I’m working on the trunk, to complete the 1.1 release of the software. It’s much more advanced than the 1.0.x branch, and given its good stability, I encourage people to use it instead, even though some planned features are still being developed.
So there’s no formal release yet, and people are encouraged to use the latest trunk revision.
This approach gives me, the main developer, a moral obligation: the trunk must NOT be broken. I’ve been very tempted to use feature branches to work around that issue, and so I created a repository at Github based on a conversion from the flvmeta SVN.
I must admit that I like Github a lot, and so I decided to maintain both the SVN and Git repository in parallel, opting not to use git-svn facilities, just to compare Git to SVN for daily tasks.
After a while I’ve started to wonder about closing the google code project in favour to Github entirely, because this double-repository thing is just an annoyance, and using feature branches in the Git version adds the risk to desync it from the SVN repository, which could confuse users.
And then, yes, they did it, Google added support for Git in Google Code ! So I uploaded my local flvmeta repository to Google Code, converted the Wiki SVN to Git, and that’s all there was to it. Now Github and Google Code are both mirrors for my local repository, and keeping them in sync is just a matter of pushing correctly.
I’m now a happy gitter, I will not come back to SVN for flvmeta. I just need to fix a few things in the build scripts, because I relied on SVN revision numbers to tag the executables during compilation, if just to make support easier by having people telling me the exact revision of the program they’re using.
It will just be a matter of using git hashes instead, there’s a handy command that I can use for that:
git rev-parse --short HEAD, or even
git describe --always.
The only thing that I don’t like with Google’s support of Git is that they decided to stick to the most used and abused protocol ever, HTTP, instead of ssh: or git:, therefore forcing me to enter my password for every interaction with their servers, since TortoiseGit won’t let me save authentification data.
I really prefer how Github handles authentication, by using cryptographic key pairs, that can be revoked individually, so if a developer machine is ever compromised, risks can be mitigated.