December 13, 2010

Configuring Surround SCM Check Out Options

E-Commerce
Surround SCM
There are two ways to run a development project:
  1. Support concurrent/parallel development by allowing anyone to commit changes to any file at any time.
  2. Prevent concurrent/parallel development, and the potential for merge complications, by requiring exclusive locks prior to committing changes.
The good news is that Surround SCM supports both models, with the check of a box.

Surround SCM Server Options dialog

Enable Concurrent Development

Under Tools > Administration > Server Options, check the Allow multiple users to check out a file box. This will enable a file to be checked out (locked) by multiple people at the same time. Conflicting changes are handled when changes are checked in (committed) to the source tree.

That second box, Allow check in of files without check out, gives users more flexibility in when they can commit changes. The classic Check out > Change > Check in can be restrictive to some developers/teams. Some teams need the flexibility to change files without having to decide right away whether those changes will end up making it into the source mainline. The Change > Check in model was popularized by CVS, and saves you the Check out step. The downside here is a lack of insight into who's changing code in a given branch, since nobody has to (essentially) state their intention of changing a file by checking it out.

Disable Concurrent Development

Under Tools > Administration > Server Options, clear the Allow multiple users to check out a file and Allow check in of files without check out boxes. This will force the user to check out the file before they can check in any changes. The check out action itself gives that user an exclusive lock on the file, which prevents anyone else from making changes for the duration of that lock. The biggest advantage here is that you avoid merge conflicts, because only one person can make changes to the file at any given point in time. The downside is that one person refactoring a class for a week could prevent five other minor fixes in that same class.