W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 19 Jun 2001 23:59:55 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103624F0A@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
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 Tuesday, 19 June 2001 23:54:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT