>--- Forwarded mail from [EMAIL PROTECTED]
>Noel L Yap wrote:
>>
>> I'm planning to use ClearCase for a new project
>I'm sorry. If you can _possibly_ get away with using CVS, do so.
>> 1. Having ClearCase do unreserved checkouts by default.
>It's possible. But if you've made changes you don't want to
>check in yet, CC doesn't give you the equivalent of "cvs up" to
>keep up with the latest.
If you write your configuration spec like this:
element * CHECKEDOUT
element * {created_since(timestamp)&&created_by(me)}
element * /main/LATEST -time timestamp
Then you have a very CVS-like environment. "cleartool findmerge"
has options to merge with the LATEST version on the branch and
modify your checkout record so that you derive from the LATEST
version. Changing the timestamp updates the files you have not
modified.
>The recommended way of doing it is for each developer to have
>a private branch. Then you can do reserved or unreserved checkouts
>on the private branch, and the CC merge tools will help keep the
>branch up to date and with merges back to the main. A wonderful
>example of how CC turns your every move into a saga.
Even if you use a private branch, then you're not really in a mode
that different from CVS; many people interpret the sandbox as a
virtual branch into which the committed changes of others are merged
via "cvs update". If you do your merges early and often, then
they're relatively painless.
In addition, most shops that use private branches provide tools that
assist with the following:
- Verify that there are no checkouts in your view.
- Lock the parent (integration) branch.
- Merge the LATEST versions of the integration branch to your private
branch. You resolve conflicts.
- Compile and test the result.
- Check in the result.
- Merge the LATEST versions on your branch back to the integration branch.
Such a merge is always either trivial or automatic.
- Check in the result.
- Unlock the integration branch.
Note that the manual steps are the same as are required in a CVS model.
The rest are completely automated.
Also note that this is only one method of many that ClearCase supports.
>> 2. Having ClearCase infer which files to operate on (ie
>> similar to plain vanilla "cvs ci").
>Don't know. How CC internally stores files depends on a heuristic
>which is pretty good, ie, binary files are stored compressed, etc.
>Note, there is no RCS keyword expansion.
No, but there are numerous contributions of triggers that implement
keyword expansions. But such features are discouraged in the ClearCase
community for the same reasons they're discouraged in the CVS community:
They mess up merges.
>> 3. Having ClearCase do atomic operations (eg either all
>> entities specified get checked in or none of them do).
>I believe you can lock the vob to prevent others from using
>it, which makes it essentially atomic (ie, no half-way state is
>possible. But I don't believe it offers "transactions", where
>if something doesn't work, you can roll back to a known state.
You can also lock branches, elements, etc. But ClearCase, like CVS,
does not implement long transactions. So you can be assured that any
operation on a file will either complete or leave it untouched (it
won't be left partly done). But atomicity does not hold for groups
of files; if ClearCase is given a list of files to operate on, then
error conditions or interrupts or system crashes can cause some files
to be processed completely while others are left untouched. The
command must be repeated when the error condition is repaired, but
this is also true with CVS.
>--- End of forwarded message from [EMAIL PROTECTED]
