ClearCase‎ > ‎UCM FAQ‎ > ‎

How do we make a work-flow look more like as in subversion?

Scenario:

Locks on chekcouts
In ClearCase files are locked for modification until they are checkedout. But in Subversion a checkout is really the equivalent of an update snapshov view and Subversion has no direct equivalent to a ClearCase checkout simply because the files are not locked for modification. In CleaCase the versions are created and FOFI - First Out First In, while in Subversion it's not important who modifies first - only who is delivering first is interesting. 

Use of streams
In ClearCase you'll typically set up separate streams for each individual developer and then work is done on these development streams and merged into an integration stream upon deliver. But in Subversion branches are typically not used a technique for isolating the developer's individual workspaces but "only" for variants and releases. The Subversion developers are isolated only by their views - and that's it.

Integration
In ClearCase when you integrate with your colleagues, you merge to the shared integration stream, and you make reserved checkouts (lock files) while you test, and when your'e done testing you can either check-in or undo checkout - depending on the result of the test. In subversion you would concuptually not push you work to your colleagues, you you would insted pull (update is the Subversion tern) your colleagues work into your own, and then test. And dependant on the test outcome you would then either commit (check-in) or revert (undo check-out).

The question is really a matter of how to map the Subversion concepts to equivalent ClearCase concepts, and bypass the ClearCase constraints.

Questions

1) How can users gain write access the files in snapshot views without leaving any locks in CleaCase.

2) How can users share a stream and only isolate themselves at view-level and not on indiviual streams.

And finally.

3) How can users accomplish to pull updates into their own workspace as opposed to push own deliveries to their colleagues.

Answers

1) Use unreserved checkouts or hijack files.
It is possible to checkout files in ClearCase without actually putting a lock on the checkout. This will allow other users to do other checkouts and and potentially checkin before others checkout. The result is de facto the same as in Subversion: The person who checks-in (commits) first will have an easy time doing so, but the ones that comes later will have to merge the new version into their own before they themselves can check-in.

An alternative is to simply hi-jack the files in the ClearCase snapshot view, that is removing the read-only bit and thus gaining modify-rights in their views, but without actually warning ClearCase that the user is currently modifying the files. Technically this is even closer to how Subversion is implemented, but the de facto result is exactly the same as using unreserved checkouts.

Whether you use hi-jacking or unreserving is really a matter of temper, ClearCase supports both. When you use unreserved checkouts the version tree will show that other users are currently also modifying the file, which might be considered nice-to-know or not-important - you choose. 

The work-flow is slightly different: When you checkout unreserved you do it at the time where you wish to gain modify rights to the file, then you modify it, and when you are done you check in the file. If you are the first to "commit" then that's it. But if you are not first your check-in is halted and you are instead required to merge the new version into your own version and then when you are happy with the you can check in the result (at which point you'll not be halted, because now you have merged the files). 

If you hi-jack files then you flip the read-only bit of the file when you want modify rights and then when you want to checkin you will have to chekc-out first (!). The way you do this is to update the snapshot view and on the advanced tab of the dialogue you telle the update to "chekcout hi-jacked files". If you are first i all goes smooth and files are checked out and you are then free to check them in again. If you are not first, then you are asked to merge the newer versions into your own and when you are done with that, the files are again checked out - and can be checked in.

2) The concept of a Shared stream is very easy to implement in ClearCase. Simply setup a new stream and let each individual developer create their own view upon the same streams. (from ClearCase Project Explorer right-click on the streamsnd select "Create View") - and you'll effectively be sharing it.

3) Using Unreserved checkouts or hi-jacking files in ClearCase will have the (in this case desired) side effect that you are not allows to check-in unless you are in sync with the underlying stream, which in this setup is set to be a Shared stream and thus you will effectively be pulling your colleagues work into your own - and then delivering. As desired.



NB: Double-click on the images to see them in natural size.
Comments