• 1
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Currently, we must specify at least one user to have access to a given branch. This ticket is a request to add a check box that says "Lock Branch," or at least take out the one-user minimum requirement.

      Allow a branch to be "locked" and prevent further operations on that branch.

            [BSERV-3064] Allow "branch locking"

            Our scenario for wanting to lock a branch is the following.

            We constantly develop on our main branch and eventually create a release branch. Once a release is blessed we want to ensure no changes go there unless we have some ceremony unlock it and make the changes. We have several parties all over the world working on development and communicating a release branch is done and no work should be done on it is sometimes hard. 

            If we lock the release branch we can ship it to clients without worry.

             

            Chuck Smith added a comment - Our scenario for wanting to lock a branch is the following. We constantly develop on our main branch and eventually create a release branch. Once a release is blessed we want to ensure no changes go there unless we have some ceremony unlock it and make the changes. We have several parties all over the world working on development and communicating a release branch is done and no work should be done on it is sometimes hard.  If we lock the release branch we can ship it to clients without worry.  

            jens added a comment -

            To be frank, setting up a blank pre-receive hook that exits 1 is very easy to do with Git. Regardless of the reason why, Stash shouldn't interfere with our ability to manipulate Git's core functionality - especially given the $12k price tag.

            Stash will make this even easier by allowing you to manage pre-receive hooks via the Stash UI. This request could then easily be implemented as a pre-receive hook if the current branch permissions are not sufficient.

            jens added a comment - To be frank, setting up a blank pre-receive hook that exits 1 is very easy to do with Git. Regardless of the reason why, Stash shouldn't interfere with our ability to manipulate Git's core functionality - especially given the $12k price tag. Stash will make this even easier by allowing you to manage pre-receive hooks via the Stash UI. This request could then easily be implemented as a pre-receive hook if the current branch permissions are not sufficient.

            Ted Sheibar added a comment - - edited

            Agreed. In our case, while it's a bit Draconian, it helps us to enforce Code Complete. This way, as commits are needed to be pushed into a release branch past Code Complete, they can be vetted and approved, instead of being "slipped in" last minute.

            Another use case is if we want to change the location of a repository. It's very useful to lock the branches of the old repository as a programmatic reminder to developers who try to push to it, thereby avoiding confusion later on at release time.

            To be frank, setting up a blank pre-receive hook that exits 1 is very easy to do with Git. Regardless of the reason why, Stash shouldn't interfere with our ability to manipulate Git's core functionality - especially given the $12k price tag.

            Here is our workaround: we set branch permissions through the API on a particular branch, restricting it to only one user - a service user to which only Release Engineering has access:

            curl -u #{user}:#{password} -i -H "Content-Type: application/json" 
            -d '{"value":"refs/heads/#{branch-name}","type":"BRANCH","users":["#{svcuser}"],"groups":[]}' 
            -X POST "https://#{mystash.com}/rest/branch-permissions/1.0/projects/#{project-key}/repos/#{repo-name}/restricted"
            

            Ted Sheibar added a comment - - edited Agreed. In our case, while it's a bit Draconian, it helps us to enforce Code Complete. This way, as commits are needed to be pushed into a release branch past Code Complete, they can be vetted and approved, instead of being "slipped in" last minute. Another use case is if we want to change the location of a repository. It's very useful to lock the branches of the old repository as a programmatic reminder to developers who try to push to it, thereby avoiding confusion later on at release time. To be frank, setting up a blank pre-receive hook that exits 1 is very easy to do with Git. Regardless of the reason why, Stash shouldn't interfere with our ability to manipulate Git's core functionality - especially given the $12k price tag. Here is our workaround: we set branch permissions through the API on a particular branch, restricting it to only one user - a service user to which only Release Engineering has access: curl -u #{user}:#{password} -i -H "Content-Type: application/json" -d '{"value":"refs/heads/#{branch-name}","type":"BRANCH","users":["#{svcuser}"],"groups":[]}' -X POST "https://#{mystash.com}/rest/branch-permissions/1.0/projects/#{project-key}/repos/#{repo-name}/restricted"

            markmielke added a comment -

            Locking a branch can be for a few purposes:

            1) Ensure stability of the branch while other things are happening. For example, while verifying a particular build. If many systems are changing simultaneously it can be difficult to figure out where a problem was introduced. During certainly critical periods, keeping as many things unchanging as possible is a requirement.

            2) Prevent mistakes by leaving the branch as a place holder so that it can be easily found, but locking out all writes to require explicit project admin override before changes can be made. This could be done for old product releases that there is no intent to patch.

            Basically - if you have 100 people working on a project, you need to be able to enforce policies. "Not writable" is a policy. Sure, you could exempt one person - but that one person may be the person who makes the mistake!

            markmielke added a comment - Locking a branch can be for a few purposes: 1) Ensure stability of the branch while other things are happening. For example, while verifying a particular build. If many systems are changing simultaneously it can be difficult to figure out where a problem was introduced. During certainly critical periods, keeping as many things unchanging as possible is a requirement. 2) Prevent mistakes by leaving the branch as a place holder so that it can be easily found, but locking out all writes to require explicit project admin override before changes can be made. This could be done for old product releases that there is no intent to patch. Basically - if you have 100 people working on a project, you need to be able to enforce policies. "Not writable" is a policy. Sure, you could exempt one person - but that one person may be the person who makes the mistake!

            jens added a comment -

            Can you explain the use-case for this requirement? What's the purpose of "locking a branch"? The current requirement is in place because we believe it is confusing to add a restriction with no user. We would likely have to change the interface to make it more explicit.

            jens added a comment - Can you explain the use-case for this requirement? What's the purpose of "locking a branch"? The current requirement is in place because we believe it is confusing to add a restriction with no user. We would likely have to change the interface to make it more explicit.

              Unassigned Unassigned
              tdavis TylerA
              Votes:
              14 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated: