[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: pre-lock.bat Failed in Repo browser

From: Michael Diers <mdiers_at_elego.de>
Date: Tue, 15 Mar 2011 08:40:18 +0100

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.)


- --
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

Received on 2011-03-15 08:40:59 CET

This is an archived mail posted to the Subversion Users mailing list.