RE: Re: [Issue 533] New - implement reserved checkouts

Btw, I totally agree with Brane here. If I had my way, I'd recommend the
following approach for handling "locking" with respect to how Subversion
operates. This is based on a tweak of how VSS works btw, and it works
fairly well.

* Support whatever DAV LOCK/UNLOCK semantics necessary for
non-Subversion clients.
* Implement the pluggable diff/merge mechanism based on MIME type we've
been talking about for ages.
* If the file can be diffed and merged then we can create an advisory
lock. i.e. clients can display who else (and possibly more than one
person) is modifying a file.
* If the file can't be diffed and merged (text files of course can
always be diffed and merged) then a reserved LOCK occurs.

Obviously, this isn't a cooked design. I'm not quite so thrilled about
non-historic properties on things for keeping track of locks. I don't
think locks are going to be quite that simple.

What happens to a lock when a file undergoes various copy/move
operations? Does the lock apply to a NodeRevision that has been cheaply
branched but hasn't yet been modified? etc....

I also agree with Brane that cooked in support into Subversion for this
just shouldn't happen for 1.0.

Your friendly schema helper taking a stab at the requirement list,
Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 15:57:51 2002