W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: "latest" resource

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 22 Dec 2000 09:16:53 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569BD.0032FF3F.00@d06mta07.portsmouth.uk.ibm.com>


> On Thu, Dec 21, 2000 at 12:26:29PM +0000, Tim_Ellison@uk.ibm.com wrote:
> > > Is there a way to tell a VCR to "float" with the
> > > latest version automatically?
> >
> > No.
>
> Grr. This seems a bit bizarre. Of the version control systems
> that I've used (RCS, CVS, SourceSafe), they've all had floating
> VCRs (effectively). That DeltaV lacks the same concept is quite
> astonishing...

Remember that VCRs do not reference particular versions, they are based on
versions.

I have no objection to including this.
It should be optional.  Locked VCRs should not 'float' when new versions
are created.

> > > I've got a strange feeling that if you CHECKOUT a
> > > version resource, modify it, then do a CHECKIN, that
> > > the VCR that pointed at the original version resource
> > > doesn't get auto-updated to point at the latest
> > > version.
> >
> > You should listen to that strange feeling!  It's right.
>
> *grumble*

A VCR doesn't point to a version resource (but I know what you mean).  This
distinction is important.

However, if you CHECKOUT & CHECKIN a VCR that will create a new version
resource, and 'copy' the content and dead properties to the VCR.

> > > Is there a way to do this automatically? If not, then
> > > what is involved with keeping VCRs pointing at the latest?
> > > Do I need to issue a bazillion SET-TARGET requests?
> >
> > Yup, you have to issue your bazillion requests.
>
> That simply blows.

If you're going to scale up to multi-server versioning with distributed
history, it is just too painful to go around and update all those VCRs.

> > The alternative is that CHECKOUT/CHECKIN fail because some client has a
VCR
> > locked and you cannot honour the auto 'latest' for them -- even
assuming
> > that you know on which server the VCR resides and can modify it.
>
> People can't lock stuff on my server :-), so I'm not worred about this.

That would help but we can't alienate locking clients.

> Hmm. I just thought of something. Assume you have two people: Joe
> checks in a bunch of stuff, creating new version resources. He
> then follows with a bunch of SET-TARGET methods, so the VCRs get
> update. Jane fetches the VCRs and sees his changes.
>
> Now... what if Joe was replaced by an automatic process? From Jane's
> standpoint, she doesn't care *how* the VCRs are updated, just that
> they are.
>
> In other words, I might argue that the server can pretend there
> is somebody out there updating all the VCRs in the repository to
> point to the "latest" revision. The logs don't show it :-), but it
> is happening.
>
> Does the spec forbid this? :-)

No, the spec does not forbid this.  I'd like to see if we can agree on
something and work it into the spec.

Tim
Received on Friday, 22 December 2000 04:19:17 GMT

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