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

Re: "latest" resource

From: Greg Stein <gstein@lyra.org>
Date: Fri, 22 Dec 2000 01:32:59 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20001222013259.A22947@lyra.org>
[ accidentally sent privately; Tim okay'd going back here... ]

On Thu, Dec 21, 2000 at 01:20:16PM +0000, Tim_Ellison@uk.ibm.com wrote:
> Greg Stein wrote:
> > 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.

Heh. Never really thought of them as separate, but yah... I see that.

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

Well, it looks like I can explicitly update them with some changes Geoff
made in the MERGE method. Specifically, that you can MERGE an activity now,
which seems to imply: check all the buggers in to get your new version
resources, then merge those into the VCRs.

As Geoff points out, using MERGE this way will mean that the client no
longer "expects" the VCR to float, but is specifically asking the server to
do the checkin and VCR change.

> > > > 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.

Not on our system. When you fetch, it just grabs the latest. We aren't
actually making copies or updating VCRs at all. You could consider it a
"lazy update", but even that is a bit false since there is no (cached) state
associated with the VCR.

> > > The alternative is that CHECKOUT/CHECKIN fail because some client has a
> > > 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.

Sure. I'm just saying that auto-latest works for me since I can't get goofed
up by a client locking a VCR.

But auto-latest seems moot given the MERGE changes. Then again, it might be
nice for systems that don't support MERGE / activities. e.g. imagine CVS
with a DeltaV frontend (although its bozo per-file model would probably be
okay cuz they'd probably be tweaking the VCR anyways).

> > 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.

I think Geoff came up with something that will work. I just asked for a
small clarification on whether "MERGE <activity>" implies a checkin or not.
Presuming it *does*, then I get the atomic checkin *and* the "floating" all
in one clean little package.


Greg Stein, http://www.lyra.org/
Received on Friday, 22 December 2000 04:30:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC