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 one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!