On 3/10/2011 1:14 PM, Henrik Sundberg wrote:
On Thu, Mar 10, 2011 at 7:00 PM, Eric Niebler<eric@boostpro.com> wrote:
On 3/10/2011 8:19 PM, Beman Dawes wrote:
On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler<eric@boostpro.com> wrote:
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky.
I'm interested. How would do you see that working?
How about this: when we're really close to release, the branch is locked so all commits are rejected. When someone wants to merge a fix, they ask permission. The release manager gives that one user commit access for 48 hrs or whatever. The access automatically expires.
I don't know if svn allows this kind of work flow. If not, then the branch can be locked and patches given to the release manager, who applies them himself. This is more work for the release manager, though.
We'd need an svn expert to chime in.
I've proposed this earlier: Add a precommit check, when the release branch is locked, that checks that any commit in the release path has a commit comment that is prefixed with e.g. "Authorized: ". If not, return error and write a description of how to proceed to stderr.
The result is that no one commits by mistake, and that everyone can understand what has happened and how to proceed.
Seems easy and reasonable. I'd likely make the comment more specific, like the trac comments. Something like: (authorized by beman). That way there's an audit trail. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail