Achieving Consistent Check-ins and Check-outs

Developers can use various StarTeam features to allow or avoid conflicts with other developers on the same files (in the same view). In a low-contention environment, developers can check-out files without locks, modify them, “refresh” to identify and resolve merge conflicts, and then check in modified files. All check-ins in StarTeam are atomic. If more than one file is checked in as the result of a single transaction (for example, in a change package from a View Compare/Merge session) the files and their associated process items are updated in a single action. If for some reason, the check-in fails, none of the files are checked in, and the status of the associated process items is not updated. In general, you can achieve consistent check-ins and check-outs by doing the following:

• Exclusively lock files before checking them in or out and unlock files after a successfully checking them in or out; or
• Temporarily change your view configuration to a known “stable” point

In higher contention environments, developers may want more assurance of getting consistent sets of files during check-out, that is, avoiding files that are a partial set of someone else’s check-in. The easiest way to achieve this need is “by convention”. Each developer exclusively locks all files before checking them in, and unlocks them when they are “complete”, either at check-in or soon thereafter. Correspondingly, each developer exclusively locks all files before checking them out, and unlocks them when complete. If a developer cannot get all the locks at once, they are potentially about to interfere with another developer, so they unlock files they currently have locked, wait a bit (probably talk with the developer they are conflicting with), and then try again. One implication of this “by convention” approach is that a developer could be blocked while waiting for another developer to finish-up.

A more formal way to enforce consistent check-outs is to use “view configuration”. To ensure consistent check-outs without locks, a developer can temporarily change their view configuration to a known “stable” point. In some organizations, a nightly build process creates a view label when the server is not used or lightly used. To temporarily change the view configuration from the StarTeam client, select View > Select Configuration > Labeled Configuration and choose the latest build label. (Alternatively, choose a timestamp or promotion state.) The view will switch to show the item states at the selected time, and “consistent” check-outs can be performed from there.