Begin forwarded message:
> From: "Jonathan S. Shapiro" <shap@eros-os.org>
> Here are the proposed merge/join rules for DCMS. DCMS will allow you to
> generate and apply patches that fall outside of these rules if you wish, but
> it will treate these as user-applied changes and will not attempt to
> preserve consistency across repeated merges or joins.
So, in the event that Monty and I want to collaborate on something,
Monty makes a branch, MZ, and I make branch, JCR, from the baseline, BL.
Monty alters a file, F.
So, if I want to test Monty's version of F, do I just copy F from MZ to JCR?
It seems to me that you're saying that Monty's got to put his changes back into BL, and then I have to merge/update from BL, if we're going to stay within the rules.
In TeamNet, I would wrap up Monty's changes to F in an ECO, and apply it to JCR. (This would be a merge if I've touched F, and an "update from MZ" otherwise.) In either event, I could still trivially revert to what I had before applying Monty's changes to F.
The long and short of it is, I don't see a benefit in limiting the source or destination of any merge/update operation. A rollback is a "merge from self" an update is a "merge from the workarea that we're arbitrarily calling the baseline", and so forth.
-jcr