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

Re: Managing "needs-lock" files on multiple branches

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 13 Jun 2013 16:31:30 -0400

On Thu, Jun 13, 2013 at 4:24 PM, Benjamin Fritz <fritzophrenic_at_gmail.com> wrote:
> On Thu, Jun 13, 2013 at 3:09 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Thu, Jun 13, 2013 at 4:05 PM, Benjamin Fritz <fritzophrenic_at_gmail.com> wrote:
>>> On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard <markphip_at_gmail.com> 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:
>> http://svnbook.red-bean.com/en/1.7/svn.intro.whatis.html#svn.intro.architecture
> 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
Received on 2013-06-13 22:32:03 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.