Re: short question about merge [PROPOSAL] vs. tree-deltas

> From: Philip Martin <philip@codematters.co.uk>

> I have only skimmed what you wrote but it appears that you are
> describing a series of copy, move, modify and merge events. Why
> don't you just write down those events

The events I described lead to an ambiguity for a merge algorithm
based on copy/rename/... history. After some branching, copying, and
deleting -- merge can't tell which, if any, of the directories in
TARGET corresponds to "src/doc" in ORIG.

What should merge do?

There are two "stories" that fit those copy/rename/... events. (One
about a doc directory being forked, one about two programs.) The two
stories lead to very different conclusions about "what merge should
do".

"If it hurts when you do that, then don't do that!" But the stories
point out that doing it in that way is the only way to get merge to
pick an appropriate ANCESTOR for certain subsequent subtree merges
from remote branches.

"Ok, don't do subtree branching and merging!". And that was a large
part of my point.

In:

   http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=35501

I proposed use-restrictions on branching and merging to keep merge
happy, and pointed out the implication that the restrictions suggest
using id cookies instead of rename history as the basis of tree
merging. That's far simpler to implement, and it gives users simple,
direct, and flexible control over the relevant issues.

This message (not from me), points to another use-case that could be
easily solved with id cookies:

        http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=35541

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 18 19:37:14 2003