Forum OpenACS Development: Response to ACS Roadmap from aD - worth a look for OpenACSers

We had a lot of internal debate about switching from CVS to Perforce within the engineering group (NB: only a relatively small sub-group within ArsDigita is using Perforce).  However, the arguments that Lars outlined above are accurate.  It's true that virtually anything you can do in CVS is possible in Perforce, and vice versa.  However, atomic commits are considered a real advantage, as are the way that Perforce handles branches.

Note that "atomic" here refers to atomicity across changes to multiple files.  If I commit changes to 15 files at once then p4 treats the entire set of changes as one atomic unit, while CVS handles this file by file.

Branches are advertised as a real advantage of p4.  Personally, I don't like their branching model that much, but it is definitely more efficient.  CVS only stores the head trunk revision as a complete copy of the file so that working on the trunk is fast; it stores everything else (including branch revisions) as a diff, and gets painfully slow when you accumulate a large number of changes on a branch.  From what I can tell, p4 treats each branch as a separate little trunk and introduces a different model for tracking branches.  This means that working on a p4 branch is as fast as working on the CVS trunk, you just have to learn their new semantics.  P4 also tracks which changes have been merged to which branches so that it's harder to generate spurious conflicts by merging the same thing twice.

I think most other features are a toss-up, and I still have a slight preference for CVS just because I've used it longer.

However, this should all be irrelevant because we hope to mirror the p4 depot in a CVS repository in the near future so that it's available for browsing and for anonymous checkouts.  We have technical and non-technical issues to work out first, but hopefully this will happen soon.