Bazaar

Can individual branches be manually locked?

Asked by Craig Hewetson

This would be useful for admin reasons or when a branch is being branched for a release. To avoid changes being committed during a period of time.

Also this can be used for gatekeeping a branch to authorize changes etc.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
John A Meinel
Solved:
Last query:
Last reply:
Revision history for this message
Vincent Ladeuil (vila) said : 		#1

This can be achieved in different ways (like, publishing the branch via a read-only server instead of a read/write one, or chmod'ing the .bzr/branch files) but none of them really address your need.

But a branch is (mostly) defined by it's tip revision id. Whether people still commit on that branch or not may not be that relevant if you use the revision-id to define a particular release (that revision-id will never change by design).

Why do you want to forbid commits on a dedicated branch ?

Why not create a new branch for the release instead and put that branch in a read-only place ?

Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) said : 		#2

Since my colleagues have been requested that I ask this question, I'll post their replies:

(on behalf of Matthys)
One example where we want to lock the branch is during a build on the our build server. We have a server that automatically triggers a build when a commit is done on a branch.
It obviously takes a few minutes to complete the build. It would be nice to lock the build so that no one can do updates and potentially break their local version of the code. The server would then only unlock it's branch when it has completed the build and we can see whether it succeeded or failed. We basically want to lock the box until we know whether the cat in it is dead or alive :).
In other words, we can use this mechanism to help protect ourselves against getting bad code from other
people. Now I know there are ways to get rid of the bad code once you have it, but a locking mechanism would give you one more tool in your toolbox for managing problems like this.

Revision history for this message
Vincent Ladeuil (vila) said : 		#3

Remember that branches doesn't require a working tree.

The build obviously needs a working tree, you can maintain a separate branch for the build server and pull from trunk when needed.

Now, you can also use a pre-commit hook to fire your build which will give you the guarantee that no one can commit code that will break the build. Note that using a lock as you propose will not protect you against that, you can realize that the last commit broke the build, but the commit is in.

The bzr project uses PQM to ensure that every single commit on the trunk pass the whole test suite which is even bigger requirement, have a look at http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-gatekeepers and see if it better fits your needs.

Revision history for this message
Best John A Meinel (jameinel) said : 		#4

All that said, we *don't* have a command for locking a branch/workingtree/repository. However, you can use:

from bzrlib import branch
b = branch.Branch.open('location')
b.lock_write()

There is also the 'bzr break-lock' command that can be used to both unlock, or to break a stale lock that someone else has left behind.

You can do the same thing for "from bzrlib import workingtree; wt = workingtree.WorkingTree.open(); wt.lock_write()" and locking a working tree will lock its branch.

However, looking at your request, you are actually inverting it with:

> It obviously takes a few minutes to complete the build. It would be nice to lock the build so that no one can do updates and potentially break their local version of the code. The server would then only unlock it's branch when it has completed the build and we can see whether it succeeded or failed.

If I read that correctly, you want to lock the branch so that you can't *pull* from it, not so that you can't *push* to it.

Given that constraint, I would highly recommend something like using PQM (or lp:tarmac) to manage the branch. Since it will bring in the change you requested make sure the build succeeds before committing the change to the branch (as Vincent pointed out)

Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) said : 		#5

Thank you for the information we will investigate PQM

Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) said : 		#6

Thanks John A Meinel, that solved my question.