[EMAIL PROTECTED] on 04/27/2000 12:28:52 PM
>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.
I think I'm going to like CC's dynamic views. IMHO, assuming semantics
conflicts don't occur too often, dynamic views allow working in a "Merge Early,
Merge Often" mode. This mode, in turn, allows catching merge conflicts earlier.
>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.
IMHO, the "correct" way to do any merge is within a private working area. Once
the merge is deemed OK (ie it at least builds or passes some rudimentary
testing), it's checked back in.
This means that private branches require one more merge than virtual branches.
The extra merge occurs when merging the changes from the private branch back
into the mainline.
Noel
