Branko ??ibej wrote:
> Greg Hudson wrote:
> >>+ Oh by the way, all of this implies that the server never
> >>+ transmits the lock GUID to anyone once the lock token has been
> >>+ sent to the owner after an "svn lock", otherwise you open the
> >>+ door to lock spoofing -- _not_ a good idea! --brane]
> >>
> >>
> >
> >These things seem to contradict each other, so I think I misunderstood
> >the first part.
> >
> >
> Yes, I wasn't quite clear. When the client sends a "current state" tree
> to the server, it should include any lock tokens it finds in the working
> copy. There can be only one of those per path, so the server can reply,
> "the lock on *this* path is stale" without having to send the lock token
> back to the client, or any client.
>
> Perhaps there's an even easier way; since an "svn st -u" would list
> locked files anyway, the client can notice that the lock is gone simply
> by the fact that it's not marked as locked in the status/update reply.
> Doesn't even have to send lock tokens to the server except on commit or
> unlock.
I think this second approach could have some problems. What if the
local working copy's lock had expired/been unlocked and another client
received the lock? When this WC sees that the file is locked, it
incorrectly assumes that it owns that lock. I think the client will
always have to submit its lock tokens to the server and have the
server check that they are still valid.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 04:07:35 2004