--- Forwarded mail from [EMAIL PROTECTED]
>I'm planning to use ClearCase for a new project for various reasons (no flame
>wars please). However, I kind of like some things that CVS affords. Has anyone
>had any experience doing the following in ClearCase:
Good for you!!
>1. Having ClearCase do unreserved checkouts by default.
The closest you can come to this is probably a post-checkout trigger that
forces a "cleartool unreserve". Unfortunately, ClearCase provides no
mechanism to determine if the -reserved flag was given on the command line,
so you have to kludge something up for that.
Alternatively, you can pick up the wrapper program from the contributed
software section on Rational's support site and hack up the way the
checkin command is implemented.
The first method is easiest. The second offers additional benefits, such
as opening up the possibility of per-command triggers.
>2. Having ClearCase infer which files to operate on (ie similar to plain vanilla
>"cvs ci").
Without knowing exactly what you're doing, it's hard to give a recipe. If
you really just want to check in everything that's checked out, then the
following script will do what you want:
cleartool lscheckout -recurse -short -cview | xargs cleartool checkin -cq
If you want to cancel a checked-out tree, then use this (note the sort, in
case a directory is checked out with an added file):
cleartool lscheckout -recurse -short -cview | sort -r | xargs cleartool uncheckout -rm
>3. Having ClearCase do atomic operations (eg either all entities specified get
>checked in or none of them do).
ClearCase behaves the same way that CVS does in this regard: It will check
in everything it can (as specified on its command line), stopping at the
first error or interrupt or the successful completion of all checkins. Some
people describe this as atomic behavior, others don't. Neither tool leaves
the repository untouched if any file is checked in successfully.
--- End of forwarded message from [EMAIL PROTECTED]
