Ben Collins-Sussman wrote:
> The main idea is: a user "locks" a file in the filesystem. This means
> than a new (potentially) long-lived transaction is created in the
> filesystem which represents this one locked file. There's a 1-to-1
> mapping between a locked file and a lock-txn. We keep this mapping in
> a new 'locks' table that maps a path to a txn-id.
>
> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
> * When somebody tries to read from a non-HEAD revision, everything
> is normal. When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
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.
- 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.
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, or the application layer.
To fix it at the DAV lyer, you would just have the DAV layer perform a
commit for every PUT, except if that resource was locked, then perform
a commit every time a lock is release. This scheme does break the
property that every PUT is immediately seen by other clients, however
I think it is unwise to allow unversioned data to be transparently
propagated to other clients. How would the text-base work in that
case? The client would have no idea what version of a file it had
locally and thus no means for transmitting diffs to/from the server.
Alternatively this could be fixed at the application layer, by
turning off the "auto-save" feature.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 01:24:25 2004