Skip to main content Help Control Panel

Rod Morison Software —  Technotes

Home «   Agile «   Tools and Best Practice Automation «  

SCM - My Quick Take

As a daily user and occasional administrator of SCM I've come across plenty of fact and some religion about SCM systems. Here's my take, sticking to the systems I've been hands on with.

Oh, and I'm going to make it brief. Hence, I'll avoid feature details...just IMO.
First, the systems I've have hands on experience with, both user and admin (and omitting oldsters like RCS and SCCS):

Key SCM Features

I boil the value of SCM system into a 3 level progression, with the most sophisticated systems satisfying all three. There are important features that don't fit in these groups, but in IMO, SCM systems that efficiently nail the items below really save an organization time and money.
  1. Manage multiple developer contributions and track individual changes
  2. Manage large hierarchies of source that can be combined in different ways for different product builds with lots of developers working in parallel
  3. Manage change policy, i.e., branch off a copy of source for beta test (limited developer changes) and production (no developer changes) based on policy and keep track of both policy and branches came from.
All the systems (short of the unmentioned zipfile backup SCM system) support 1, enough said. The old RCS and SCCS systems weren't good at number 2, and thus was born CVS.

CVS

CVS got it right, and was brilliant in its day, as it's long lifetime shows. Unlike the earlier RCS/SCCS systems, CVS gave each developer their own space to work in, so that you could change a bunch of files before checking them in. (Ok, you could do this with RCS, but only with a lot of 'ln -s'ing!)

However, the CVS repository has very limited metadata, needed to support item 3, and CVS suffers from potential race problems when lots of developers are checking in lots of the time.

That said, if you've got a small group, are in a hurry, and people already know CVS I wouldn't slow down for a more sophisticated SCM system. I've watched one organization wait over a year to bring their Cadillac SCM system into place and lose immensely valuable development history along the way.

Subversion

Subversion is good. It solves the race problem with CVS. It's metadata understands that files are updated in groups, not individually, which helps tie groups of changes to specific features and fixes. And, it's got a growing set of users and tools owing to the migration of many sites from CVS to Subversion.

It's a very good thing for the open source development community, which is necessarily price sensitive in the cost of its tools.

However, I wouldn't call it a "power" system, and it really doesn't address item 3, where complex commercial products really live.

Q: What's a "power" SCM problem?

A: You've got a key customer with a bug from 2 version ago, a final candidate beta under test with the qa group, proprietary customizations for 2 different customer to fulfill large orders, and most of the dev team is off coding for the next release...Subversion doesn't have that much more to help you than CVS.

ClearCase

The previous scenario is when it becomes easy to justify the cost for a power tool. If there were open source that did the job I'd be all over it.

ClearCase is the "mature" high-end product in the space. It started (years ago) as the internal SCM for Apollo Computer, which HP bought ages ago. And then someone bought someone else, and somehow IBM ended up with the darn thing. For a decade ClearCase was the only real power tool (that I knew of, at least.) That was then.

ClearCase started with a model much like the old RCS and SourceSafe systems--everybody worked in the same sandbox at the same time. That's not good for parallel development and a lot of people said "no thanks, we'll stick with CVS." (That's exactly what I said to the then Atria sales rep.)

In modern times (counted in SCM years) ClearCase has added support for parallel development. However, it's not as organic as Perforce, or even CVS for that matter (IMHO). I should really say, the old model gets in the way sometimes, and can be confusing to deal with.

ClearCase certainly has a lot of powerful features, and is one of the most 'burnt in' SCM systems in the world. But some of that power just isn't with things I need and I came away from my one ClearCase project with the opinion that it just isn't the best of bread. Further, there's nothing that distinguishes ClearCase with regards to my #3 above.

Perforce

I was working at a site with a large Perforce installation: 75 developers, over 3M LOC, very complex release schedules. A colleague and I were discussing whether we were using Perforce in the best way.

He urged me to read the Perforce white papers on branching , life cycle policy and SCM best practices (especially the latter paper). After getting over the initial "all corporate white papers are self serving marketing pieces" reaction I realized that what we had the most trouble with was addressed spot-on by Perforce's discourse on policy based branch management and ownership.

For example, developers were constantly asking "can I checkin on that branch?" or "I have a fix marketing asked for on this special customer release, who do I talk to about getting into the right branch?" There was daily confusion about who was responsible for what and what the checkin policy was.

Stepping away from that particular story, if you read the Perforce SCM best practices whitepaper, there are two things to take away:
  1. Every branch should have a documented checkin policy that every developer can lookup, without asking the VP Engineering, and
  2. Every branch should have an owner, who is responsible for what does get checked into the branch.
So, enough background. All this is fine philosophy, but what does Perforce bring to the table? If all this talk of branching large source codes doesn't scare you...well, it should. If you're going to hang your hat on policy based branches, you better be able to move code changes between branches as easily as possible.

Perforce has the best branch & merge system on the market. Note: I'm not talking about merging individual files. I'm referring to managing groups of changes between related branches and keeping track of what changesets have been integrated to what branches (Perforce specific terminology in italics.)

Furthermore, if you really want to impelement policy based branches, you want to lock branches from developers except on the valid conditions to submit a change. Automating branch level controls based on policy is an interesting and challenging Queries topic for another article. Perforce provides nice hooks for such customizations, and I'll assume ClearCase has them, too.

The Bottom Line

Far better to use CVS or Subversion now, than wait even another week. Every commercial product has support for pulling in the log messages and version diffs from those systems.

If you want the most targetted, effective solution for modern SCM, go with Perforce.

Attach a file ·  Discuss this page

Stay tuned
recent comments
podcasted files
AddThis.com