-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-03-15 00:19, Daniel Becroft wrote:
> In addition to this, locks are for a working-copy, not necessarily for a
> user. It's possible for the same user to steal the lock that they
> already hold in another working copy, and your script will let them.
Yes, that's an additional twist there alright.
Citing from "The Book":
Regarding Lock Tokens
A lock token isn't an authentication token, so much as an authorization
token. The token isn't a protected secret. In fact, a lock's unique
token is discoverable by anyone who runs svn info URL. A lock token is
special only when it lives inside a working copy. It's proof that the
lock was created in that particular working copy, and not somewhere else
by some other client. Merely authenticating as the lock owner isn't
enough to prevent accidents.
For example, suppose you lock a file using a computer at your office,
but leave work for the day before you finish your changes to that file.
It should not be possible to accidentally commit changes to that same
file from your home computer later that evening simply because you've
authenticated as the lock's owner. In other words, the lock token
prevents one piece of Subversion-related software from undermining the
work of another. (In our example, if you really need to change the file
from an alternative working copy, you would need to break the lock and
relock the file.)
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
- --
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1/F+EACgkQcEKlWnqVgz17YgCdEe7K2CrLvnorKtBoyJo3xedr
pWgAnROM4E9SSBEi1xQcHMTzEuPa9s6c
=W9Nh
-----END PGP SIGNATURE-----
Received on 2011-03-15 08:40:59 CET