Josh Pieper wrote:
>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.
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...
>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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 20 01:52:10 2004