Fw: Proposed merge rules Jonathan S. Shapiro (shap@eros-os.org)
Tue, 18 Apr 2000 00:28:23 -0400



From: "John C.Randolph" <jcr@idiom.com>
To: "Jonathan S. Shapiro" <shap@eros-os.org> Sent: Tuesday, April 18, 2000 1:13 AM
Subject: Re: Proposed merge rules

>
>
> 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
>
>
>
>