Question

I’m helping get the SCM set up for a new program, and we’re currently in the process of deciding on a VCS.

The main contenders at this point are SVN, ClearCase, SVN+DVCS, and just a DVCS.

At the moment, the team is leaning towards either SVN or SVN+DVCS. We want to avoid the expense and administration costs of ClearCase, but want the workflow and versioning options it offers. I brought forward the option of using a DVCS as well, and the idea is being considered.

For the DVCS, we’re considering Mercurial, Bazaar, and Git. The team feels comfortable with SVN, but don’t think it’ll offer the versatility needed, which is why we’re looking at the DVCS on top of SVN option.

Does anyone have any advice (e.g. existing tools, processes) for getting such a setup going?

Concerns include:

• Ease of setup
• Setting up workflows (developing <-> code reviews -> test -> trunk, then trunk -> integration test branch -> release with bug fixes put into the release branches), auditing (found a bug, when was it introduced)
• Generating metrics
• Reasonable learning curve for developers used to ClearCase.
• Windows development
• Issue tracker integration (probably going to be Redmine, though it isn’t set in stone)

Answer 1

As an administrator of ClearCase, I would rule out that tool unless you have a complex merge workflow.

The workflow you mention involves being able to branch, fix and then merge back easily, which should not be in favor of SVN.

The biggest trap when you are used to ClearCase (espacially non-UCM ClearCase) is the “composition” of a config spec.
If you choose a DVCS (Mercurial, Bazaar — or Git since it works really well on Windows), you would not be able to get the same “inheritance effect” — (when you are selecting different versions with different successive select rules —: as said in that answer:

In a purely central VCS, you can define your workspace (in ClearCase, your “view” either snapshot or dynamic) with whatever rules you want.
That would not be practical in a DVCS (as in “Distributed”): when you are making a branch with it, you need to do so with a starting point and a content clearly defined and easily replicated to other repositories.

If you are using ClearCase UCM, that means identifying coherent sets of files, which can only be achieved through – for instance – Git submodules.
The complexity is higher with those DVCS, since they do not record the dependencies between modules (or “set of files”) the way ClearCase UCM does.

So, to recap:

• Ease of setup: all the mentioned DVCS are easy to setup. What must be taken into account is the administration in terms of user access.
• Setting up workflows: a DVCS supports any kind of workflow, even a centralized one, or a public-private one, or…. Regarding finding a bug, they all support some kind of bisect process.
• Generating metrics: if by that you mean “metrics about the code managed”, they all support some complete log system able to display a lot of information about what has changed.
  But in term of “metrics about the tool” (speed of a process or space taken by data), the DVCS tools mentioned are considered much faster than SVN (see here as an example).
• Reasonable learning curve for developers used to ClearCase: the GUI can be a factor to alleviate the learning curve, but a DVCS is very different from ClearCase, as this “core concepts” answer illustrates.
• Windows development: they all work well on the Windows platform, with maybe a slight advantage (better integration) to Mercurial or Bazaar.
• Issue tracker integration (probably going to be Redmine, though it isn’t set in stone): Redmine supports now most of them (and not just SVN as it did at the beginning)