Reserved and Unreserved Checkouts

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 or in a stream. In other systems, many users can compete to create the same new version.Both models are supported by allowing tow 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. A 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 arew working in other views must merge the check-in changes into their own work before they can check in.

 

For example, one file in view A is checked out with Reserved option. The file is checked out in view B with Unreserved option too ( only can be checked out with Unreserved option since it has been Reserved by view A). That means the file in view B can not be checked in unless the files in View A has been checked-in.

 

In above example, if the file is checked out in View A and B with Unreserved option, it can be checked in at any time without considering the check-in sequence. The first check-in makes the successor version and later one will create antoher version after merge operation.

 

The status of a checkout can be changed from reserved to unreserved or from unreserved to reserved. Users can not change an unresearved checkout to a reserved checkout if the version is checked out as reserved in another view. Here are the 2 ways to do this

• • Using cleartool command

  Cleartool reserve element-name

  Cleartool unreserved element-name

• • Using the GUI

  In Rational ClearCase Explorer, select the checked-out version and click either Tools->Reserve or Tools->Unreserve

  In Windows Explorer, right-click a checked-out version. Then click ClearCase->Properties of Version.