[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 13 Jun 2013 15:47:19 -0400

On Thu, Jun 13, 2013 at 3:41 PM, Benjamin Fritz <fritzophrenic_at_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/
Received on 2013-06-13 21:47:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.