About reserved and unreserved checkouts

In some version control systems, only one user at a time can reserve the right to create a new version on a branch (using the customizable features of DevOps Code ClearCase®) or in a stream (using UCM features). In other systems, many users can compete to create the same new version. Both models are supported by allowing two kinds of checkouts: reserved and unreserved.

The view with a reserved checkout has the exclusive right to check in a new version for a branch or stream. Many views can have unreserved checkouts. An unreserved checkout does not guarantee the right to create the successor version. If several views have unreserved checkouts, the first view to check in the element on a branch or stream creates the successor; developers who are working in other views must merge the checked-in changes into their own work before they can check in. Your organizational development policy may determine whether to check out reserved or unreserved.

The figure below illustrates checked-out versions created by reserved and unreserved checkouts, and the effects of subsequent checkins.

Column one shows a reserved checkout: version three has one reserved check out and it is checked in to create version four. Column two shows an unreserved checkout: version three has two checkouts and one of the checkouts is checked back in to create version four.

With a reserved checkout, a checkin of version 3 creates the latest version on the branch, version 4. With an unreserved checkout, the first checkin creates the latest version on the branch, version 4. But a subsequent checkin of version 3 is blocked until the user merges the latest version, version 4, with the checked-out version.