Managing "needs-lock" files on multiple branches

[Benjamin Fritz <fr...@gmail.com>]

Where I work, we branch for every bugfix, to allow a "clean" trunk at all times.

Some files we work with are not easily merged, so we have
svn:needs-lock set on them.

Locking one of these files is supposed to indicate to the rest of the
team not to touch it until you're done (or at least, ask first). But
since the lock is on a branch, somebody else on a different branch, or
even merging back to trunk, will have no way to know you are editing
the file.

I wanted to solve this using a pre-lock hook on the server, which
would automatically try to lock the trunk version of an artifact when
somebody locks on a branch. But, since locking requires a username and
password, and hook scripts do not have access to that information, the
best I could do is deny the lock if the trunk is not locked, and also
if the existing trunk lock does not contain the branch name in the
lock comment.

I might be able to get a special user added, with a password that
never expires, which the hook script could use with a hard-coded
password to create the trunk lock.

Is there a nicer way to create a trunk lock from the hook script? I
don't know if "the powers that be" will approve of a special user for
this purpose. Or perhaps an alternate solution to allow branch locks
to actually be useful? I sold the team on a pre-lock hook in the first
place with the idea that it could be fully automated, I'll need to
sell them again if there is an extra manual step in there.

Most of us use the TortoiseSVN GUI rather than command-line tools, so
a simple wrapper script to invoke instead of using "svn lock" directly
isn't a very nice option either.

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

[Mark Phippard <ma...@gmail.com>]

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

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

[Benjamin Fritz <fr...@gmail.com>]

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

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

[Mark Phippard <ma...@gmail.com>]

On Thu, Jun 13, 2013 at 4:05 PM, Benjamin Fritz <fr...@gmail.com> wrote:
> On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard <ma...@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

>> In SVN 1.8, the svnadmin command can be used as well:
>>
>> $ svnadmin help lock
>> lock: usage: svnadmin lock REPOS_PATH PATH USERNAME COMMENT-FILE [TOKEN]
>>
>
> 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.

> 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.

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.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

[Benjamin Fritz <fr...@gmail.com>]

On Thu, Jun 13, 2013 at 2:47 PM, Mark Phippard <ma...@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?

> In SVN 1.8, the svnadmin command can be used as well:
>
> $ svnadmin help lock
> lock: usage: svnadmin lock REPOS_PATH PATH USERNAME COMMENT-FILE [TOKEN]
>

I don't know what version of SVN is running on our server, but I know
it is definitely less than 1.8, sadly.

> Use --bypass-hooks to avoid
> triggering the pre-lock and post-lock hook scripts.
>
> Valid options:
>   --bypass-hooks           : bypass the repository hook system
>

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?

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

[Mark Phippard <ma...@gmail.com>]

On Thu, Jun 13, 2013 at 3:41 PM, Benjamin Fritz <fr...@gmail.com> wrote:
> Where I work, we branch for every bugfix, to allow a "clean" trunk at all times.
>
> Some files we work with are not easily merged, so we have
> svn:needs-lock set on them.
>
> Locking one of these files is supposed to indicate to the rest of the
> team not to touch it until you're done (or at least, ask first). But
> since the lock is on a branch, somebody else on a different branch, or
> even merging back to trunk, will have no way to know you are editing
> the file.
>
> I wanted to solve this using a pre-lock hook on the server, which
> would automatically try to lock the trunk version of an artifact when
> somebody locks on a branch. But, since locking requires a username and
> password, and hook scripts do not have access to that information, the
> best I could do is deny the lock if the trunk is not locked, and also
> if the existing trunk lock does not contain the branch name in the
> lock comment.

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.

In SVN 1.8, the svnadmin command can be used as well:

$ svnadmin help lock
lock: usage: svnadmin lock REPOS_PATH PATH USERNAME COMMENT-FILE [TOKEN]

Lock PATH by USERNAME setting comments from COMMENT-FILE.
If provided, use TOKEN as lock token.  Use --bypass-hooks to avoid
triggering the pre-lock and post-lock hook scripts.

Valid options:
  --bypass-hooks           : bypass the repository hook system


--
Thanks

Mark Phippard
http://markphip.blogspot.com/