Zachary Gorden wrote:
This is common practice before a release and has been done for at least the last year or so.
You make it sound like locking the whole trunk and making the majority of developers unable to work properly is a state we want to keep. Of course, this has mostly been done due to having no alternatives when using Subversion and our urgent need to fix these blockers. But still, it's generally the worst possible action I can think of when it comes to collaborating on Open-Source projects...
... which raises the question about switching to a distributed version control system for me again.
While Subversion has proven to be a viable solution for most of our needs, we still have to cope with its drawbacks from time to time. The major ones I can think of include:
* Build breakages in trunk prevent other developers from working.
Although some devs might have already get used to occasional build breaks, this could become a bigger problem when, for example, two developers constantly commit to a common component and update their working copies afterwards. They would immediately be forced to stop their work and wait for a fix, when a build break occurs, even if it's lying in a completely different component.
With Git or Mercurial, we could make wholly different workflows possible here. A better one might be that each developer only works on their own branches (which can be local and/or remote). Optionally, two or more developers working on the same component could also commit to a common branch, but still independent of the trunk or master branch. If one needs stuff from a different branch, he can easily merge single commits or fetch all changes from a branch.
Though SVN of course also provides branches, merging is far away from being a transparent and trivial task there. I guess that the devs, who often deal with our SVN branches, can confirm this. Git or Mercurial solve this task way better.
* Not all commits in trunk are well-tested and easily make it unstable.
The recent locking of trunk again showed that it's still a place where every trusted dev can, roughly speaking, commit whatever he wants. It should be obvious that this leads to unexpected problems from time to time. Many people might also well remember the GL case, when the drastic action of limiting one developer's SVN write access to branches was done to prevent him from committing possibly problematic stuff to trunk.
Using the branch workflow as described above would circumvent both problems and even make trunk an unattractive place to work on. If people have their own branches, where they can do everything they want, to prepare a big change (e.g. that network locking rewrite), nobody should ever need to work directly on trunk again. We would just need to establish new rules or methods to get commits from the branches into the trunk/master branch. Maybe a combination of automatic and manual testing (depending on the situation) can help us here.
Such problems will turn out to be more severe with the raising number of developers.
While this topic has already been partly discussed last year, the comfortable Windows support (= TortoiseSVN-like shell extensions) for both Git and Mercurial was still in very early stages of development at that time. This situation has improved much in the meantime. TortoiseGit and TortoiseHg should both provide most of the functions we need.
The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more in the general concepts.
As Git was designed with Unix principles in mind, it shares its one-tool-for-every-task approach. This way, it includes over 100 individual tools today to somehow solve every task and workflow. The official version also does not support Windows, but as msysgit and TortoiseGit exist today, this should be negligible. TortoiseGit is directly based on the TortoiseSVN source, so you should find it pretty easy to use.
Mercurial was designed with more usability and interoperability in mind, so it's properly supported under all major platforms. Compared to Git, it only supports the most common commands. On the other hand, its TortoiseHg was designed the same way, meaning that it's a GTK application targeted to run under several platforms as well. Therefore the user interface is quite different to that of TortoiseSVN.
After this rather long mail, I hope that we can eventually come to a conclusion about which distributed version control system to choose. Our existing Git mirror should be suitable for evaluating Git and I'm also doing a local import of the SVN repository into Mercurial right now (yes, it seems to work this time).
By the way, we can still maintain a SVN backend for the trunk/master branch afterwards, so that people may still read the repository the same way as they have done before.
Best regards,
Colin