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.
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.
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.
3) How can users accomplish to pull updates into their own workspace as opposed to push own deliveries to their colleagues.
1) Use unreserved checkouts or hijack files.
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.
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.
NB: Double-click on the images to see them in natural size.