subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Phippard <>
Subject Re: Managing "needs-lock" files on multiple branches
Date Thu, 13 Jun 2013 20:31:30 GMT
On Thu, Jun 13, 2013 at 4:24 PM, Benjamin Fritz <> wrote:
> On Thu, Jun 13, 2013 at 3:09 PM, Mark Phippard <> wrote:
>> On Thu, Jun 13, 2013 at 4:05 PM, Benjamin Fritz <> wrote:
>>> On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard <> wrote:
>>>> The hook is running on the server, so it could access the repository
>>>> via file:// URL to do the lock.  This does not require authentication.
>>> I DID NOT KNOW THIS! Is that documented somewhere? This should allow
>>> my pre-lock hook to work exactly as I wanted! What other svn commands
>>> that also behave this way?
>> Which other commands support file:// ?  All of them do.  file:// is
>> one of the supported "RA" mechanisms for Subversion - ra_local.  See:
> I knew about file:// access, I just assumed username and password
> would still be required when using it. But looking at the
> documentation I see a few notes (in sections about tunneling) that the
> only control on access is the filesystem permissions on the DB files
> themselves. Do I understand correctly, that if a user can access the
> files within the actual SVN repository filesystem location, then that
> user can use any "svn" commands without a password?

Yes.  If you have read/write access to the repository filesystem you
can also manually delete revisions or try to edit them with a text
editor as well.

> I saw notes on a few forums during my searching for answers to this,
> about avoiding using svn commands that would recursively trigger the
> same hook script. I assume that is just because I need to be careful
> not to cause unbounded recursion. I though I'd ask, however, to make
> sure SVN won't have problems because it is already processing a
> pre-lock hook when it gets another lock request.

OK, I understand now.  SVN will not have a problem, the key is your
hook will be called again.  So your hook needs to be smart enough to
say "hey this lock is for trunk, I do not need to do anything".  Then
you will be fine.

> I think for now we'll just --force the trunk lock/unlock when needed.
> I can't think of a good way to unlock via hook script, because
> unlocking the branched file only means the changes for that particular
> commit on the branch are done, not that the file is OK to edit now on
> a different branch or trunk (since it hasn't been merged back to trunk
> yet).

Makes sense.


Mark Phippard

View raw message