On Thu, Jun 13, 2013 at 4:24 PM, Benjamin Fritz <fritzophre...@gmail.com> wrote: > On Thu, Jun 13, 2013 at 3:09 PM, Mark Phippard <markp...@gmail.com> wrote: >> On Thu, Jun 13, 2013 at 4:05 PM, Benjamin Fritz <fritzophre...@gmail.com> >> wrote: >>> On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard <markp...@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/
