Re: FW: A question about branching, mer

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Thu, 9 Dec 1999 23:21:20 -0500 

Date: Thu, 9 Dec 1999 23:21:20 -0500
Message-Id: <9912100421.AA02866@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256841.006D3BD1.00@d54mta03.raleigh.ibm.com>
Subject: Re: FW: A question about branching, mer

   From: jamsden@us.ibm.com

   <jim/>
   This sounds like it breaks the revision history of a
   versioned resource. Don't think we want to allow that.

   <tim/>
   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.

   <jim/>
   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.

What change to the predecessor/successor relationships are you
referring to here?  If you are resolving a conflict by merging
tips of the parallel lines of descent, none of those are inherently
"the predecessor" with the others being "merge predecessors".
It is only our current model that forces you to artificially
distinguish one from the others.

If you want to describe the merge in some way (e.g. its purpose), the
appropriate place to do so is the activity that is capturing the
results of the merge.

   From: "Eric Sedlar" <esedlar@us.oracle.com>

   I agree that keeping them separate is the right idea.  There's no reason to
   lose this information, which could be very useful for clients.

What information is being lost?  How would a client use it?
In particular, what information is being lost that wouldn't
be better captured by appropriate annotations on the merge
activity?

Cheers,
Geoff