> >My first impression is that this scheme adds significant complexity,
> >where a simpler method would suffice. The simpler method:
> > - Have the a locks table which any client may access. Only one
> > client may hold a lock for a given path.
> That would make it impossible to implement shared locks
> (a.k.a.notifications), and I don't think we want this restriction unless
> it's really necessary, which I don't see at this point.
> > - At commit time, the server may check the committed paths to see if
> > any of them are protected by locks. Conceivably if all clients
> > that wanted to edit a file were "nice" and held the lock before
> > modifying it, then this check would not be necessary.
> "The lock". Which lock? You still have to verify the authenticity of the
> lock token. You don't want to allow your clients to spoof lock tokens...
That is what I meant, but it may not have been as clear as possible.
> >I talked on IRC with Ben about why the long-lived transactions were
> >chosen over this simpler scheme. The motivation seemed to be that
> >with DAV mounts, every single "auto-save" of a file would create a new
> >revision. With committing a revision automatically upon UNLOCK,
> >hopefully the number of revisions would decrease as most clients only
> >issue an UNLOCK when they are truly done with the file.
> >I think a simpler solution would be to attack this at the higher
> >layers: either through DAV autoversioning,
> A separate feature that we have now and will want to keep anyway...
> >or the application layer.
> Oh no, that's not acceptable. "If you want to use Word with a Subversion
> server, turn off autosave". Yikes.
No, more like, "If you want to use Word with Subversion and don't want
_all_ of your changes versioned, turn off autosave."
Does the WebDAV spec explicitly state that versioning only occurs at
UNLOCK time? If not, then it is possible that other WebDAV
implementations could behave in the same manner, i.e. every PUT is a
commit. This advice would also apply to operating Word on any
versioning filesystem, not just WebDAV.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 20 02:03:45 2004