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

Re: "latest" resource

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 21 Dec 2000 12:46:58 -0500 (EST)
Message-Id: <200012211746.MAA07229@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

I think the current (10.11) draft gives Greg what he want here.  In
particular, I'm proposing that we allow a MERGE request to checkin
every checkout in an activity (previously the spec was silent on this

This means that rather than the "atomic activity CHECKIN" that Greg
asked for before, he instead has "atomic activity CHECKIN and MERGE"
which I think is what he really wants.  Greg, can you confirm/deny?

A few more comments below.

   From: Greg Stein <gstein@lyra.org>

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

With the above MERGE behavior, you do have the ability to tell the
server to move forward to all the new versions you are creating, which
I believe is the "float" you want here.

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


Hopefully this update to the protocol will allay that strange
feeling (:-).

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

I agree.  A bazillion requests is a lot of requests.

   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? :-)

Nope.  All you lose is interoperability (because your client is unlikely
to get this behavior on any other server, and another client would be 
surprised to see this happen on your server).

BUT, I believe what you want to happen is very reasonable, so if the MERGE
proposal works for you, we have a nicely interoperable way for you to tell
your server what to do.

Received on Thursday, 21 December 2000 12:47:50 UTC

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