- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 22 Dec 2000 09:16:53 +0000
- To: ietf-dav-versioning@w3.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... 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 UTC