Source Control Checkins


I have deleted libsgdcore_diff_file.c.

Note that these operations have not actually happened yet.  They won't happen unless I submit them to the server, at which time they will take place as a single atomic transaction.

Vault persists the pending change set between sessions.  If I shutdown my Vault client and turn off my computer, next time I launch the Vault client the pending change set will contain the same items it does now.

The Church of "Edit-Merge-Commit"
Up until now, I have explained everything about checkouts and checkins in a very "matter of fact" fashion.  I have claimed that working files are always read-only until they are checked out, and I have claimed that files are always checked out before they are checked in.  I have made broad generalizations and I have explained things in terms that sound very absolute. 

I lied.

In reality, there are two very distinct doctrines for how this basic interaction with an SCM tool can work.  I have been describing the doctrine I call "checkout-edit-checkin."  Reviewing the simple case when a developer needs to modify a single file, the practice of this faith involves the following steps::

  1. Checkout the file
  2. Edit the working file as needed
  3. Checkin the file

Followers of the "checkout-edit-checkin" doctrine are effectively submitting to live according to the following rules:

  • Files in the working folder are read-only unless they are checked out.
  • Developers must always checkout a file before editing it.  Therefore, the entire team always knows who is editing which files.
  • Checkouts are made with exclusive locks, so only one developer can checkout a file at one time.

This approach is the default behavior for SourceSafe and for Vault.  However, CVS doesn't work this way at all.  CVS uses the doctrine I call "edit-merge-commit."  Practicers of this religion will perform the following steps to modify a single file:

  • Edit the working file as needed
  • Merge any recent changes from the server into the working file
  • Commit the file to the repository

The edit-merge-commit doctrine is a liberal denomination which preaches a message of freedom from structure.  Its followers live by these rules:

  • Files in the working folder are always writable.
  • Nobody uses checkouts at all, so nobody knows who is editing which files.
  • When a developer commits his changes, he is responsible for ensuring that his changes were made against the latest version in the repository.

As I said, this is the approach which is supported by CVS, which actually has no support for exclusive checkouts at all.  Vault supports edit-merge-commit as an option.  In fact, when this option is turned on, we informally say that Vault is running in "CVS mode."

Each of these approaches corresponds to a different style of managing concurrent development on a team.  People tend to have very strong feelings about which style they prefer.  The religious flame war between these two churches can get very intense.

Holy Wars
The "checkout-edit-checkin" doctrine is obviously more traditional and conservative.  When applied strictly, it is impossible for two people to modify a given file at the same time, thus avoiding the necessity of merging two versions of a file into one.  

The "edit-merge-commit" teaches a lifestyle which is riskier.  The risk is that the merge step may be tedious or cause problems.  However, the acceptance of this risk rewards us with a concurrent development style which causes developers to trip over each other a lot less often.

Still, these risks are real, and we will not flippantly disregard them. A detailed discussion of file merging appears in the next chapter.  For now I will simply mention that most SCM

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.