[MERGE] Add an optional 'token' keyword argument to LockableFiles.lock_write

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> [According to my mail client, your mail client seems to like inserting tabs in
> long subject lines.]

Hey, don't we all?

Seriously, I don't know why it's so hard to write a really good
graphical mail app.  T-bird's the least bad I've found, but if you've
got a suggestion...

> Aaron Bentley wrote:
>> The possible weakness I see here is, how do we know which lock token to
>> supply?  It seems like we would need to guess.
> 
> You supply the one you have from a previous lock_write.
> 
>> Would it be better to supply all known tokens?
> 
> I have no idea what you're suggesting here.
> 
> The use for this is in the smart server.  The smart server process is stateless
> (the only state is what is recorded in the branch/repository) and this is a
> property we need to keep.  However, holding a lock is stateful, and so we need
> some way for the server to obtain the same state the client is in when it is
> doing something for the client.

Ah, I see.

I see lock tokens as a solution to a slightly different problem:
double-write locking for dumb (and potentially smart) transports.

Every now and then, we encounter a situation in which the same
repository is being write-locked twice.  This is often because there are
two branches which are using it simultaneously.

These situations can usually be detected by looking at the repository
base, but not always.  There are various scenarios where repositories
may be aliased to several locations, e.g. with symlinks, domain PTR
records or by providing the same repository over multiple protocols.  So
resolving them by looking at base location isn't a strong enough guarantee.

So far, we've addressed these issues by carefully tinkering with the
order in which locks are taken, and the kinds of locks that are taken.
This approach works, but it feels fragile.

If write_locked objects had tokens associated with them, then we could
detect double-lock scenarios, and (I think) eventually handle them
seamlessly[1].

But if the problem is that you're trying to lock a resource that is
aliased to another already-locked resource, the problem is that you
don't know which token to supply, because you don't even know about the
aliasing.

> I hope I've explained this clearly; it took me a while to understand and
> remember what was needed here, but Robert eventually got it to stick :) 

Thank you, yes.  I was confused by the fact that you were also pursing a
way to double-lock resources, and I didn't understand the details.

But perhaps my idea can be pursued as a second phase of your idea.

Aaron

[1] Perhaps we would have to combine the open and write-lock phases, so
that if we already have a locked object for that resource, the existing
object is returned, rather than returning a new object.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF1HML0F+nu1YWqI0RAp0TAJ4twg1+sTIFdS5jPUTJ/3MY7ZxTtwCfXLis
pCOBBR9bD3rdanotufmb4Yk=
=RbhI
-----END PGP SIGNATURE-----