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

Lets move forward and remove it from the protocol.

At 11:59 PM 6/19/01 -0400, Clemm, Geoff wrote:
>Actually, I shouldn't have used the word "variant" since that has a
>specific HTTP meaning (an alternative form of a resource content,
>such as another language), and I was using it to mean "a resource that
>will have a separate version history, but which is based on a version
>from another version history".
>
>I think the working group consensus is to just get rid of it until
>it gets more support, so unless you are strongly attached to it,
>I'd like to resolve this particular issue by pulling DAV:precursor-set
>from the protocol.
>
>Cheers,
>Geoff
>
>-----Original Message-----
>From: Rick Rupp [mailto:rick.rupp@merant.com]
>Sent: Tuesday, June 19, 2001 8:08 PM
>To: ietf-dav-versioning@w3.org
>Subject: Re: Actually, you don't need COPY or MOVE, what you really seem
>to want is CLONE.
>
>
>I agree with the group that there are other ways to track relationships
>between version histories. If this is the only use case for the
>precursor-set and the consensus of the group is it should be dropped, I'm
>okay with this decision.
>
>I understand what a variant is however I don't fully understand how the
>precursor-set is used to create one in a workspace. If that is how variants
>are created then I recommend the precursor-set be kept and moved from the
>version-control feature into the workspace feature.
>
>At 10:34 AM 6/19/01 -0400, Jim Amsden wrote:
> >I guess I agree with John. This sort of information is generally kept in
> >comments or application specific properties. The question we have to ask
> >ourselves is if there is any need to have precursor information available
> >in an interoperable way. I don't know off the top of my head any other
> >system that supports this, but it could be something I just never used.
> >
> >I also agree with Geoff in that there are good arguments either way.
> >However I'd lean in the direction of leaving things out if there is any
> >doubt. They can always be added in later when we have more experience and
> >the use cases are more crisp. We don't want to hold up the protocol on
> >such issues either if we can help it.
> >
> >
> >
> >
> >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 Wednesday, 20 June 2001 12:00:54 UTC