RE: Actually, you don't need COPY or MOVE, what you really seem t o want is CLONE.

I went thumbing through the archives (which I should have done
in the first place ...), and found another motivation for
the DAV:precursor-set property.

A workspace is only allowed to have one VCR for a given version
history, to ensure that baselining and merging is unambiguous
(baselining and merging in a workspace is based on finding the
version history that corresponds to the version being merged),
so if you want to create a "variant" of a resource in the same
workspace, this requires two different version histories.
In order to track the relationship between these two variants
(i.e. when the diverged, and from what common version), the
DAV:precursor-set property was introduced.

It was then decided by the working group that this "history of
a COPY" was something of general utility (using arguments similar
to those that Rick posted), and since it provides utility with
minimal server implementation cost, it was made part of the base
protocol.

With respect to John's argument that a resource created by COPY
has its content "overlaid" by later changes, that's the case for
any new version in a version history as well, so I don't see this
as an argument against tracking this relationship.

So in conclusion, although it is fair to ask the working group
to defend any element of the protocol (and desireable to remove
anything that has no such defense), I believe the case for the
DAV:precursor-set has been resurrected, so an implementation
difficulty would need to be identified in order to remove this
protocol element.

Cheers,
Geoff

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Tuesday, June 19, 2001 1:45 AM
To: 'John Hall'; 'Rick Rupp'; ietf-dav-versioning@w3.org
Subject: Actually, you don't need COPY or MOVE, what you really seem to
want is CLONE.


I still can't see where it is useful to know about two different version
histories, one that you have poor information on (the source of the
COPY) and an old version history that is no longer relevent to the
actual content (since you overlayed it).



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of John Hall
> Sent: Monday, June 18, 2001 8:30 PM
> To: 'Rick Rupp'; ietf-dav-versioning@w3.org
> Subject: RE: [ietf-dav-versioning] <none>
> 
> 
> I disagree.
> 
> I see no difference between creating a new version from 
> scratch and copying data from somewhere else to create a new 
> version from scratch. If I open file1 and then do a save-as 
> on file2, the server doesn't know and precussor isn't set in 
> any case.  So why is it so important to know that someone 
> grabbed a copy of file1's current version and copied it to 
> file2 without editing it first?  If you really want the 
> version history, use MOVE not COPY.
> 
> Do you have a 'for example' use case where that origin 
> information is valuable?  And would it still remain valuable 
> after a few more edits were done?
> 
> 
> 
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Rick Rupp
> > Sent: Monday, June 18, 2001 5:39 PM
> > To: ietf-dav-versioning@w3.org
> > Subject: [ietf-dav-versioning] <none>
> > 
> > 
> > The precursor-set property seems to be an important concept
> > of a versions 
> > history. Without it there is no indication that a version has a 
> > relationship to another version history.
> > 
> > I don't think it will be unusual for a client to create a new
> > version by 
> > copying from a different version history. Will it be 
> > important to know the 
> > new version came from a different version history? I think 
> > the answer is 
> > yes and the precursor-set facilitates this.
> > 
> > 
> > 
> 
> 
>

Received on Tuesday, 19 June 2001 07:29:16 UTC