Rather than write about the
NYT magazine article on electronic voting machines and their failures that
everyone else is writing about (or simply pointing to) I want to share a bit of an email exchange I had with someone who posted to CraigsList for “subversion help”. (No, this is not meant to be something the
Sedition Act would get me on, but rather the
version control system of that name.
Just to get this out front, since some people who know me might think this is meant to be mocking of my correspondent: it most certainly is not in any way meant to be disparaging to anyone, only enlightening (I hope).
He starts with:
How do we protect our trunk from bad coders/commits without spending too much time in administration, merging, Etc. Most of the developers will be new to SVN. There will be at least a dozen developers, several with language and communication barriers. Our site is live and needs lots of bug fixes so quick response is needed as well as protection of the trunk against bad code.
This isn't really a 'subversion' question, strictly speaking, as it really is more of a 'process' question. You'd encounter much the same problems in ANY version control system you used.
The larger and more successful open-source projects survive on this by having a careful vetting of committers and a strong QA process.
After reviewing this page: http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html and looking at the following sections "The Never Branch System", "The Always Branch System", and "The Branch When needed System".
The branch when needed system sounds good, and I can think of having a bugfix branch separate from new features. What is the best approach for this type of development house that lacks an SVN expert and needs to rapidly deploy bug fixes and new features which still protecting the trunk.
Just do as they say—create a subversion ‘branch’ and switch to it, and then you may need to keep track of what changes are made to the branch that may also need to get brought back into the main code base.
That last part is a non-trivial administrative headache. (We had to do this for another client of ours until I convinced him that having a branch that was effectively his “test area” and a main line that he merged into was trouble.)
Merging is ALWAYS a headache, can SELDOM be done automatically and is fraught with subtle peril.
My advice is to avoid branch/merge as much as humanly possible, unless you really need to run two parallel development efforts (say, supporting a legacy system in version n while developing a new, incompatible, featureset in version n+1).
For a small site or service that is managing its assets via subversion, you'd probably be much happier in having a test server where daily commits can be seen automatically, and then having the project manager or operations manager do the rollouts to production to a specific, known subversion version number that has passed QA.
(Of course, the key is to make sure that the developers do a subversion update [svn up] before they do any work to make sure that they're not undoing what someone else is doing...)
Having had to manage distributed developers—even those just in the US48, all of whom were native speakers of English—it was almost one FTE of my staff just managing software versions to rollouts with QA and the development staff.
If your development staff is all new to subversion (but is familiar with other tools, either things like cvs or perforce) you may be in luck, but if not, it is worth the effort to make sure that someone that manages them understands version control systems and can make suitable and sensible commits.
As much as everyone loves to hate them, you might want to take a page from Microsoft, and make sure that people are held tightly accountable for their commits. (See http://www.joelonsoftware.com/articles/fog0000000023.html)
Joel writes:
One rule we followed on the Microsoft Excel team, to great effect, was that whoever broke the build became responsible for babysitting builds until somebody else broke it. In addition to serving as a clever incentive to keep the build working, it rotated almost everybody through the job of buildmaster so everybody learned about how builds are produced.
It may not be practical to use that particular carrot and stick for your teams, so you'll have to be creative.
Second, we don't know how to integrate trac with subversion.
We've never done it, either, although we've looked into it. There are many good places to start:
http://trac.edgewall.org/wiki/TracSubversion
http://www.yolinux.com/TUTORIALS/LinuxSubversionAndTracServer.html
