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

Actually, this is the long-awaited much needed:
"DeltaV Book of Why Not" (a companion document to
Yaron's "WebDAV Book of Why".  It is currently up
for public contributions in the DeltaV auto-FAQ
page, set up by Tim Ellison a while back on the
deltav web site (thanks again, Tim!).

So please contribute anything you think of value to
this document.  When it has sufficient mass, I'd be
happy to format it in the form of an informational
RFC, so we can get it published as a companion document
to the protocol.

I would object to folding all this material into the
protocol itself, since it is much too easy to misconstrue
the motivational statements as normative statements.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Tuesday, June 19, 2001 7:54 AM
To: ietf-dav-versioning@w3.org
Subject: AW: Actually, you don't need COPY or MOVE, what you really seem
t o want is CLONE.


I think this thread calls for the definition of a "Quantum Property"
which is spontaneously created and annihilated and exists in a
probabilistic state as long as nobody looks into the mailing list
archives.

Clients and servers implemented during this time, will share the
probabilistic state. It will be unknown if they are brilliant
or rather a piece of junk until "Geoff starts thumbing".

Notice that a collapsed quantum property can be made probabilistic
again when
a) someone asks a questions about it on the list
b) enough time has gone by that Geoff did last "thumb".
c) it is not mentioned in the spec what happened last time

I therefore propose to document the result of "thumbing" in
the Spec.

Regards, Stefan

> -----Ursprüngliche Nachricht-----
> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> Gesendet: Dienstag, 19. Juni 2001 13:35
> An: ietf-dav-versioning@w3.org
> Betreff: 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 09:11:55 UTC