Begin forwarded message:
> From: "Jonathan S. Shapiro" <shap@eros-os.org>
> Date: Mon Apr 17, 2000 09:28:43 PM US/Pacific
> To: "DCMS List" <dcms-dev@eros-os.org>
> Organization: The EROS Group
> X-Mailer: Microsoft Outlook Express 5.00.2919.6600
> Delivered-To: dcms-dev-list@eros-os.org
> X-Priority: 3
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> X-UIDL: c18a87dfe0f03bee63699711cfe71366
> X-MSMail-Priority: Normal
>
> [This is a response to John's note that I just forwarded to the list.]
>
> There are two ways that JCR and Monty can collaborate.
>
> First, Monty can simply publish his branch, and JCR can obtain it directly.
> This doesn't merge the two branches.
>
> Second, JCR can obtain a diff incorporating Monty's changes, and apply it to
> the JCR branch. This accomplishes what JCR seems to want, but breaks the
> tracking of merge/join.
>
> You can always obtain diffs and apply them; I don't propose to do away with
> that. The rules describe those merge and join sequences that DCMS can keep
> track of automatically.
>
> The reason for the restriction is that I can't figure out how to implement
> something.
>
> Suppose we *merge* Monty's changes into JCR's branch (i.e. in a way that
> DCMS understands). We now have
>
> Monty branch = base + monty changes
> JCR branch = base + monty changes + JCR changes.
>
> While JCR checks out Monty's cools stuff, Monty makes one more change and
> joins his branch into the trunk. We now have
>
> base' = base + monty changes'
> JCR branch = base + monty changes + JCR changes
>
> JCR now decides to join his branch. He must first integrate:
>
> JCR branch = base + monty changes' + monty changes + JCR changes
>
> It's kinda like driving in Italy. Collision city.
The rule is, the person merging has to resolve the conflicts. In this scenario, what should happen is, my attempt to merge after monty shows that (All but one of Monty's diffs in JCR are a NoOp), and the last one he made gives me an update conflict which I must resolve in order to check in. I can resolve it either by updating JCR with Monty's last diff (Wasn't that a movie from the 1940's?) or by using my authority to alter BL and either keep or remove Monty's diff as I'm adding mine.
I presume that what happens here typically, is that a collision results in me having to manually resolve the conflicts in a nice, GUI diff-viewing tool like Apple's FileMerge, or the like.
> Until I figure out (or somebody gives me) a change algebra that can track
> these changes well enough to do a plausible job on the merge I'ld rather
> stick to what I know how to do and leave the hard cases for people like John
> to manage by hand.
Well, it's always managed by hand when there's a check-in conflict. That's the way it's always been, and that's the way I see it for the forseeable future.
> At the very least, I'ld like some strategy for recording enough about these
> "perverse merges" so that the merge tracking system can know that something
> irregular has happened.
How is it irregular? It's just like any other case of having a stale version in your work area.
-jcr