RE: Protected properties...

It's because the precursor defines the logical ancestor to the version from
a different version history.  The precursor is a resource that the client
chose to copy or merge into the working resource / checked out version
controlled resource because it made ('application') sense for them to do so;
whereas the predecessor defines the resource that was actually checked out.
This distinction was considered important.

Some systems may not support changing the value of the resource that was
actually checked out, hence the predecessor MAY be protected, however, of
course the precursor cannot have such system limitations and therefore has
no right to be protected.

Tim

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 01 June 2001 20:22
> To: DeltaV
> Subject: Protected properties...
>
>
>
> DeltaV lists one property, DAV:predecessor-set, that MAY be protected on a
> checked-out resource, it's up to the implementation.  However, on
> a version,
> predecessor-set MUST be protected.  So far, so cool:  I understand that.
>
> Next, note that precursor-set is NOT protected on a checked-out resource,
> but MUST be protected on a version.  Might some implementations choose to
> protect precursor-set in all cases as well?  Why is precursor-set handled
> differently than predecessor-set?
>
> lisa
>

Received on Saturday, 2 June 2001 18:56:35 UTC