2003-11-04 12:00:00

Source Control for One, Part Two

There is one thing I forgot to mention in my blurb last night about source control for single developers.

Background:

There are two basic models for how a developer interacts with a source control repository:

"checkout-edit-checkin":  A working copy of the repository files is maintained on the client machine, and the files are marked as "read-only" when they are retrieved.  The developer uses the Check Out operation to get a copy of the file which she intends to edit, and that file is then changed to be writable.  When the edits are complete, the file is checked in and the working file is once again marked read-only.  VSS works this way.

"edit-merge-commit":  Once again, the client machine has a working copy of the repository files, but those working files are left in a writable state.  When the developer is ready to edit a file, she doesn't need to do anything to let the source control tool know about it.  Just edit the file as if source control were not involved.  When it's time to checkin those changes, the tool will notice which files have changed and be ready to commit those changes to the repository.  It may be necessary to perform a merge if somebody else has modified the file in the meantime.  CVS works this way.

Shameless plug for my product:

SourceGear Vault supports either of these models, depending on the option settings.  By default, Vault uses the "checkout-edit-checkin" model, for consistency with VSS.  But it's easy to switch into what we call "CVS mode".

The thing I forgot to say:

The cool thing to notice is that when using source control all by yourself, the "edit-merge-commit" style degenerates to simply "edit-commit".  If you're thinking source control for a single developer is just too much of a pain to be worth the trouble, you might try using a tool that supports "edit-merge-commit".  Source control can be very unintrusive when working that way.