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?
>>> In SVN 1.8, the svnadmin command can be used as well:
>>>
>>
>> I don't know what version of SVN is running on our server, but I know
>> it is definitely less than 1.8, sadly.
>
> SVN 1.8 has not been released yet. Was just pointing out that this is coming.
>
Yes, I know. I meant I know for a fact we're not using an unreleased
version, and highly suspect it will take a long time (if ever) for us
to upgrade.
>> I've made sure the pre-lock hook will succeed under normal
>> circumstances (i.e. file is not locked, or --force was passed) if the
>> file is NOT on a branch. So a recursive call to lock a file NOT on a
>> branch shouldn't be a problem, right?
>
> Not sure I understand the question. You probably just have to test
> the scenario and see what output the command gives you.
>
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.
> Note that you are going to need to a means to remove these locks. You
> ought to be able to do unlock with hook scripts, just test it well and
> make sure you accounted for everything.
>
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).
Thanks for all your help!
Received on 2013-06-13 22:25:28 CEST