Comments on: MInimum Requirements for a CMS

By: Asher Sterkin

Asher Sterkin — Fri, 01 Dec 2006 17:30:08 +0000

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.

By: Sebastiano Pilla

Sebastiano Pilla — Fri, 01 Dec 2006 16:58:27 +0000

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”

By: Walter Underwood

Walter Underwood — Thu, 30 Nov 2006 22:28:06 +0000

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.

By: Anonymous

Anonymous — Thu, 30 Nov 2006 03:39:00 +0000

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.

By: Chip Patton

Chip Patton — Wed, 29 Nov 2006 22:52:19 +0000

Eric Sink’s “Source Control HOWTO” is a pretty good reference (http://software.ericsink.com/scm/source_control.html).
CVS Best Practices is another (http://www.tldp.org/REF/CVS-BestPractices/html/)
I haven’t had a chance to use Subversion yet, but it may have a canonical reference also.

By: Kevin Furbish

Kevin Furbish — Wed, 29 Nov 2006 19:44:09 +0000

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.

By: Jim Bullock

Jim Bullock — Wed, 29 Nov 2006 07:43:28 +0000

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.

By: Martin

Martin — Wed, 29 Nov 2006 05:10:00 +0000

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!

By: Tom

Tom — Wed, 29 Nov 2006 02:19:02 +0000

If you have more branches than “current production” and “head” then you should try harder

By: Joe Grossberg

Joe Grossberg — Wed, 29 Nov 2006 01:56:15 +0000

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.