Bill Tutt wrote:
>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.
>
+1. Obviously.
>* Implement the pluggable diff/merge mechanism based on MIME type we've
>been talking about for ages.
>
This has nothing to do with locking, even given what you say below.
>* 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.
>
I'm leaning against having two kinds of locks, and would prefer to have
mandatory locks only.
>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?
>
You can copy a locked file, in which case the destination is a new
object, and obviously not locked. You just can't commit a change to a
locked file (unless you're the lock owner, of course). Therefore, you
can't move/rename a locked file.
(Yes, I know that internally we have a unix-like implementation, where a
rename is really a modification of the parent directory. IMHO locking
should work more like renames, deletes, etc. in a Windows filesystem,
where these are operations on the objct itself, and controlled by the
object's ACL.)
> Does the lock apply to a NodeRevision that has been cheaply
>branched but hasn't yet been modified? etc....
>
A lock refers to a certain revision/path combination. The revision can
either be explicit (e.g., you can lock an old version of a file, thereby
forbidding branching from that version --- and I realise this is in
direct contradiction to what I said about copying above), or implicitly
HEAD.
>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,
>
Thanks!
Come to think of it, here's how ClearCase implements reserved checkouts.
When you check out an element, it actually creates a _new_ version of
that element on the branch, and locks access to _that_. This prevents
other people from checking out on the same branch, but allows them to
create new branches from the last checked-in version. (This would
correspond to the implicit-HEAD revision I mentioned above, _and_ it
would imply that creating a lock means creating a long-lived txn on the
server. But I digress). In ClearCase, you can also lock an old version;
you can't create branches from that version. This is all consistent,
because nobody but the lock owner acutally sees the "virtual"
checked-out version.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 18:26:35 2002