MInimum Requirements for a CMS

 

I’m writing part of the PM book, and said this about the minimum requirements for a configuration management system (CMS):

Modern CMSs can branch, label, automatically merge multiple authors’ changes, and allow for developers to work in their own private workspaces (sandboxes). If your CMS can’t do that, dump it and obtain a new one.

The reason I’m saying this is because I still see people using CMSs that don’t allow for sandboxes, don’t branch easily, and don’t perform automatic merging well. It slows development (and the project) down dramatically. Did I miss anything?

Update as of Dec 1: I changed the acronym in the book to SCM. Did a global find and replace and it’s done. Phew!

14 Replies to “MInimum Requirements for a CMS”

  1. On that front, Subversion is by far the best way to go. I’ve used it on small, personal projects all the way up to 200+ kloc with minimal problems. I’ve even gotten a few designers, doc-guys, and my non-technical wife into the mix with 5 minutes of traigning.
    Slight nitpick…
    CMS is the generally accepted term for *content* management system.
    For configuration management, source code management (SCM), concurrent versioning system (CVS), or version control system (VCS) are generally more useful terms.

  2. A CMS that doesn’t support pre- and post-commit hooks gets an automatic demerit.
    Pre-submit hooks let you do things like automatically enforce some code guidelines (e.g., “No copyright string? And you’re not on the list of approve exceptions? Away with you!”)
    Post-submit hooks make it easier to set up thing like per-checkin test runs and selective emails.

  3. Integrating new vendor releases should be non-hard. It doesn’t need to be easy, but doing that in CVS was really grim and some systems are not much better. You really, really want your team to use external libraries, so you don’t want the SCM system to be an obstacle to that.
    I’ve never used pre- and post-commit hooks, except for commit e-mails. I’m not a big fan of enforcing coding rules in the system. If the coding rules aren’t in the culture, putting them in the system doesn’t help much.
    I’m vary wary of a long list of required features. An over-complex SCM system can be more of a problem than an under-featured one. In one company, the group using CVS got a lot more done than the one using ClearCase. CVS is limited, but it is fast and you can write scripts to help it along. These days, use Subversion instead, of course.
    Speed is huge. Checkouts/updates must be instant. If a checkout takes 20 minutes, developers will not do one every hour.
    I agree that CMS means content management system.

  4. Hi Johanna,
    I’d also look for the following:
    1. Configurable mail notifications
    a. Groups
    b. Individuals
    c. Event-based
    2. Management dashboard (metrics)
    The notification aspect comes into play when things change and people need to be notified (particularly when a major change to source code or documentation occurs). The dashboard is becoming increasingly important as a communication tool for management, i.e., if you can’t measure it and present the measurements in a meaningful way, management may not “get it”.

  5. Keith is right. I’m a professional web developer and I immediately thought “Wow, that’s a high standard for content management!”
    In any case, I would add free (or affordable) and well-documented to the list.

  6. Hi Johanna,
    I wouldn’t list requirements and suggest dumping a tool if they are not met. It really depends on the needs and budget of the project. Subversion is great because it is cheap. ClearCase has most of the bells and whistles but very expensive to implement. I have projects that still use PVCS because we don’t need “sandboxes.” We are fine with single stream development.
    Also, no tool automatically merges 100% of the time. You will have conflicts.
    Other factors that weren’t mentioned:
    – Operating system(s)
    – Bandwidth
    – Distributed/Local development teams
    – web enabled
    – integration with Defect tool
    – size of files (disk space)
    – number of users
    Good luck with the book!

  7. Well, Dave Smith chimed in with part of what I wanted to say, as he often does. I’ll expand a bit on “hooks” below.
    The big trick for a versioning system for project management is how it supports managing the project. So workflow, check-ins and so on is nice. Visibility into the state of the code base, and volume of activity is more nice. It needs to help with things like knowing the velocity, tracking what’s “done” and not, traceability to whatever kind of planning / projecting you’re doing and so on.
    The point of a versioning system for *managing* a project is how it helps you with your baseline – the knowing what you’ve got part of managing a project.
    About “hooks” I’ll just add that they can be more than static inspections. They are there for *anything* you want to wire in before or after, two ways 1 – Fire something off to do what it does and 2 – BLOCKING as in the commit doesn’t go in until this external thing here we fired off comes back with an ACK.
    I’d much prefer an API into the versioning system as well, but that’s just me.

  8. I’ll third the comments suggesting the SCM acronym over CMS. I immediately thought Content Management System when I saw the post title.
    I’d also include the ability to work across an entire source tree instead of file by file. When you want to know what files a user has changed recently you don’t want to go search each file individually. And when you want to do a merge you want to make sure you merge everything with changes on the branch using a single operation and don’t miss some anything going file by file.
    Another common operation that I find invaluable is “annotate”. For every line of a file it lists what version last checked in that line. It’s invaluable when you’re tracking down where a bug was introduced.

  9. Modern version control systems also version the developers’ private workspace and then let the developers commit all their intermediate versions back to the mainline when they are done. This lets them work while disconnected without losing the ability to record version information. Subversion is a bit out of date in this respect: when disconnected you can revert your changes back to the version you checked out when last connected but not record new versions.

  10. Joel Spolsky posted today about the hairy SCM issues in Vista: http://www.joelonsoftware.com/items/2006/11/29.html
    For Vista, the minimum requirements are far beyond the maximum capabilities of some SCM systems.
    Really, the tool depends on the team and the project. I’ve seen SCM “requirements” which were caused by excessive coupling in a product which they were attempting to fix with a tool. That doesn’t work. Re-architect for modularity, then use a simpler tool.
    If the SCM system is a big cognitive load on the developers, you have a problem. More features won’t fix that problem.

  11. Me too on the CMS/SCM thing… you’ll confuse a lot of people if in your book you write CMS where most of the readership will assume “Content Management System”

  12. Integration with Defect Tracking system (Bugzilla, ClearQuest, etc.) is a must in my view. I too often see source code polutted with defect tracking system comments. Working smoothly in a multi-site environment for a reasonable would be the next. For example, ClearCase is very network intensive and will hurt you if your the cross-cite communication is bandwidth bounded and your IT department is not ready to pay extra for its multi-site version. I like the ClearCase UCM approach, but it costs a lot and still does not support some quite obvious features such as reverting to the base line in one touch. To sum up, it’s a complex issue still far from having a good generic solution.

Leave a Reply