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.
-- Brane
---------------------------------------------------------------------
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:52:10 2004