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.
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::
- Checkout the file
- Edit the working file as needed
- 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.
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