Version Control System for small, in-house team

Question

We are a small, in-house development team (5 people) who are developing a few Joomla (PHP) components for release. We need a version control system of some sort (preferably with some soft of integrated bug tracking) and none of us have any experience.

We currently all simply work on the same files on a central development server but need to have better version control as the projects are growing in complexity and we will start making regular releases.

The one major draw back that I can see is that we will most likely have to all install Apache locally so that we can "check out" the project locally and then "commit" back to the central "trunk" or whatever it is called.

I think we can live with this, although it would be preferred if we could just keep everything on the development server.

Anyway... we initially settled on Mercurial as that seems popular and "the new kid on the block", but now that I have read some more it seems that Mercurial is primarily for distributed teams. Now I am starting to lean more towards SVN as we will not need to create lots of branches etc.

Maybe we don't need any of them? Any advise is much appreciated.

Answer 1

…it seems that Mercurial is primarily for distributed teams.

Just because you can use a DVCS in a distributed way doesn't mean you must. Setup a central repo on a server for everyone to use and treat Mercurial (or Bazaar or Git) as a centralized VCS. Over time you may come to appreciate the additional features of a DVCS, but you can ignore them for as long as you like.

DVCS articles, documentation, and so forth do tend to lean more heavily on the distributed nature than is perhaps warranted, but they do because being distributed is what sets DVCS tools apart from the rest. Practically everything people already know about general VCS concepts, practices, etc. still applies.

Answer 2

I would stick with Mercurial. There is nothing that prevents you from using Mercurial the same way you would use SVN. Just create a central repository somewhere and call that repository your "main" or "root" repository. Whenever anyone commits a change, they should push to the central repository, and whenever anyone wants updates they should pull from it.

Later, when you start too feel the need to use feature branches and you will be very happy that you are using a source control system that supports this - and Mercurial has much better support for branching than SVN.

If you need integrated bug tracking I can recommend using Trac, as that plays very well together with Mercurial.

Answer 3

SVN, git and Mercurial are the "big names". Personally, I found SVN to be rather intuitive, especially for people who have used other centralized VCS suites before (SourceSafe, CVS, stuff like that). Mercurial and git certainly add value, but they are also more complex to understand (*) at first.

And yes, you absolutely do need a VCS system. Even if you are working on a piece of software alone, never work without VCS. At the very minimum it's a convenient backup feature. The rest you will realize once you run into problems ("who did break that feature, when, in which release, and why?").

(*): I said understand, not use. I just don't like to use software I don't understand first, and I found it more difficult with git.

Answer 4

I have no experiences with Mercurial or Git, but it is often stated that Subversion has the best GUI client support. I'm a very happy user of the famous TortoiseSVN for Windows and also Eclipse (as many other IDEs) has a very good SVN integration.

You don't have to all install Apache locally. That must be a misreading.

Answer 5

The basic principle of development using version control is that each user has a copy of the source code, which they modify and test on their local machine. The repository then provides the means of integrating everyone's changes.

So you're pretty much right when you say you'll need apache and joomla installed on your local machines in order to use it. My first piece of advice is to embrace this model, rather than trying to work around it and somehow all work on a shared checkout.

VCSs with integrated bug tracking are fairly rare, but solutions do exist (TFS, PureCM), if you're willing to pay. Otherwise, choose bug systems that do their bit well and integrate with the source control you're using - like Redmine or Trac.

Also consider using something like Hudson to pick up the latest changes from source control and automatically deploy them to a test site and possibly run tests on them as well. Even for something like php code which isn't compiled, it's often useful to check that the latest version installs and runs. Also, Hudson can be used to build your release package. The idea is that if you build a release package automatically every time something changes, then it's not a big deal when you come to make the real one.

Since you're a new team, I'd recommend jumping straight in with a DVCS - it's the latest generation of VCS and it'll be easiest to pick up this model from the start. Avoid things like CVS and VSS, as they're a good generation out of date and their data models are wrong-headed when you move to a more modern system (SVN upwards).

Your VCS system is (relatively) hard to change once it gets bedded in to the team, so it's worth getting feelers from the others about what will be accepted by the team and what won't.

Finally, you might find good ol' hginit to be a good starting point for learning and teaching people how to use distributed version control.

Answer 6

I'd stick with Mercurial if I were you. It's better technology, simple as that.

Subversion is well supported by third party tools, but it will take you only so far: it works very well for new projects, where everything is just in development, but sooner or later you will come to release your code, and when that happens, you will need to support concurrent development, and that means you will need to sustain at least two branches, possibly more.

Subversion's support for branching and merging is still very immature, buggy, restrictive and overly complex. For example, once you have reintegrated a branch back into trunk, you have to either delete the branch, or else resort to complex, error-prone workarounds in order to keep it alive. (See the relevant part of the Subversion manual, this answer, and my recent blog post on the subject.)

In addition to supporting concurrent development, easy branching and merging has several other benefits. For example, you can have a branch for weekly sprints running concurrently with more complex, six-to-eight-week tasks, or you can have experimental branches for when you need to try out two or three different approaches to a problem.

Mercurial also supports features such as patch queues and chunk selection, which lets you separate out your work into a series of logical, single-responsibility changesets rather than having to mix several different things together. This comes in useful if you ever have to go back over your history and see why a certain change was introduced. Another feature that can be worth its weight in gold is "bisect": this lets you drill down very quickly through your history to find the revision that introduced a bug.

Answer 7

SVN and Bugzilla.

Answer 8

Give a try to Plastic SCM Community Edition. It's free for your team and is probably the most comprehensive one for branching and merging.