Re: DAV:predecessors vs. DAV:predecessor/DAV:merge-predecessors
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Mon, 20 Dec 1999 22:36:33 -0500
Date: Mon, 20 Dec 1999 22:36:33 -0500
Message-Id: <9912210336.AA07961@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525684D.00500119.00@d54mta03.raleigh.ibm.com>
Subject: Re: DAV:predecessors vs. DAV:predecessor/DAV:merge-predecessors
I agree that one could distinguish one predecessor as being special
(i.e. the one that was "checked out" vs. the ones that were "merged"),
but what I was looking for is some convincing use case for how one
would *use* that information later on.
Cheers,
Geoff
From: jamsden@us.ibm.com
The only thing that's lost is the ability to distinguish a
predecessor/successor relationship resulting from a direct checkout/checkin
from one that was created by a merge. Althought there's no real difference,
one might say that a merge implies different behavior by users that they
might not want to loose.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/19/99
A couple of weeks ago, I proposed simplifying the spec by unifying
a revision's DAV:predecessor/DAV:merge-predecessors into a single
DAV:predecessors. The discussion has been generally supportive of
this change, but there have been folks who didn't like it.
I'd like to ask anyone who *doesn't* like the change to please submit
a use case where this change produces a loss in functionality.
If none can be identified, I'd like to make the simplification.
Note that we can always add a DAV:predecessor property afterwards if
we discover a need for it, but for now, I'd like to simplify the
protocol as much as possible, unless the use case is a key one.