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