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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-06-13 22:32:03 CEST