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? >>> 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!