Re: FW: A question about branching, mer
jamsden@us.ibm.com
Wed, 8 Dec 1999 14:51:43 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256841.006D3BD1.00@d54mta03.raleigh.ibm.com>
Date: Wed, 8 Dec 1999 14:51:43 -0500
Subject: Re: FW: A question about branching, mer
The breaking of history is changing the predecessor/successor relationships
after the merge was done to some other, perhaps completely unrelated
predecessors/successors. I have seen a lot of end users distinguish between
not only merges, but who did the merge and when. I just think this will be
generally useful information, and the optimization isn't worth loosing it.
Tim_Ellison@oti.com (Tim Ellison OTT) on 12/08/99 02:25:51 PM
To: ietf-dav-versioning@w3.org (ietf-dav-versioning), Jim
Amsden/Raleigh/IBM@IBMUS
cc:
Subject: Re: FW: A question about branching, mer
>This sounds like it breaks the revision history of a
>versioned resource. Don't think we want to allow that.
If the resource is a merge result of two or more 'source' resources, I
claim
that there is no reason to believe that the CHECKOUT'd resource has any
more
precedence in the revision history than other contributors to the merged
resource.
I agree that in general people will choose the closest match as a starting
point for the merge, but 'closest match' is in the eye of the client, they
might not choose a closest match, or there may be no such concept.
Why does it break the revision history? The history _is_ the merge.
Tim