From users-return-18287-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Thu Jun 13 19:42:02 2013 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 44F2CCEB0 for ; Thu, 13 Jun 2013 19:42:02 +0000 (UTC) Received: (qmail 10919 invoked by uid 500); 13 Jun 2013 19:42:01 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 10264 invoked by uid 500); 13 Jun 2013 19:42:00 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 10254 invoked by uid 99); 13 Jun 2013 19:42:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jun 2013 19:42:00 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fritzophrenic@gmail.com designates 209.85.215.175 as permitted sender) Received: from [209.85.215.175] (HELO mail-ea0-f175.google.com) (209.85.215.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jun 2013 19:41:55 +0000 Received: by mail-ea0-f175.google.com with SMTP id z7so4240692eaf.6 for ; Thu, 13 Jun 2013 12:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UgyT77y0FAOZd+DAnipm67/oomht4E5ZNiiXtG7cAGk=; b=kftme1E0RzahPBHhB6XFCPFX1TgIQm0R+G6Mr+9dCVUgXYzBCAZvXABl9mRsfXZimr DxwWS+bA5XiW3LGZ3xoThVMfm+FdwFuqEz1hiKHSCaWc8AjZTXEkkPwzCJRefeWk4jbP 1ncSfUsSu9OXeixG62D+h/aZEn/e/L2maLjOMTqCOU0oWbQR75k7slgAbDl0DyIvVCl2 hKm3n9sAnxi0eQHmz1rQXwGlj37sR7x8ee3a++yFTT7pg8CEO0PwyimN/v8QKdc30x57 kUV3jkyiq80hZIAe2i0iwd/n5OPwWhRsFyrW3+G4sB8n9LEJXOko7r4sS7cDs97+ipsB QuwQ== X-Received: by 10.15.31.9 with SMTP id x9mr2875068eeu.103.1371152493766; Thu, 13 Jun 2013 12:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.210.69 with HTTP; Thu, 13 Jun 2013 12:41:13 -0700 (PDT) From: Benjamin Fritz Date: Thu, 13 Jun 2013 14:41:13 -0500 Message-ID: Subject: Managing "needs-lock" files on multiple branches To: users@subversion.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 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.