Understanding Version Control Systems – Bazaar with Launchpad

This article will cover mostly bazaar as git is still complex for part II. Bazaar is mostly widely used along with Launchpad, so this article would also contain lots of launchpad and bazaar references. Before reading this, please read the previous post>.

From the previous post you learnt:
  1. Getting the code
  2. Making changes
  3. Saving your changes
  4. Checking and analysing your changes and sync with team
  5. Revision numbers.

The understanding of these is needed for further reading.


Branches can be explained as a unit of parallel work. When multiple people get the code, they have their own local copy of the branch.

Whenever you want to work on a project which uses any version control system(VCS), the general workflow is
  1. Get the code
  2. Make the changes
  3. Commit the changes
  4. Submit the changes
  5. Your changes make it's way in the official codebase

Each of the step can differ slightly in each of the VCS. Each VCS can have more than one way to execute any of these steps. The way these steps are executed also depends on how the whole project works.

Let's imagine you are working on the codebase of zeitgeist. Zeitgeist development happens on lauinchpad and it uses bazaar as it's VCS. Now let's see how the whole thing should work

Bazaar branch URL format

You need to branch the code from the remote server, also called the central repository. Bazaar can also work without launchpad, but it's lanchpad integration makes the work a lot easier. Let's branch the code

bzr branch lp:zeitgeist

The lp: is a shortcut and the bazaar-launchpad integration resolves the whole thing and gets the code from http://launchpad.net/zeitgeist which is the code you see over here

Handling branches

In Bazaar each branch is contained inside a folder. So basically you can branch the code into multiple folders and work parallel on it without knowing what the other branch has. This means that multiple people can together work on the same codebase without worrying about who else is working on the same codebase.

Every branch can be present locally on your disk as well as on the remote server – in this case launchpad. If you need to make some changes to a remote branch, you need to fetch it from the server using the bzr branch command, then make changes, commit and push to the same branch. Note that you might not be able to push to that branch if you don't have it's ownership. This case will be discussed now. You can then also make further changes to your branch and push them to the same location.

After you are done with the work on your branch, you commit your changes and push your code on the server in a new remote branch. Example this way

bzr push lp:~yourusername/projectname/branchname

like in my case it would be

bzr push lp:~manishsinha/zeitgeist/testing-branch

all these branches are visible at the URL – http://code.launchpad.net/zeitgeist

Similarly the other users can also make changes to the codebase and push their branches in the similar fashion. Two branch names can hardly clash since you cannot push branches under someone’s else name

The branch which is denoted by lp:projectname and in this case being lp:zeitgeist denotes the primary branch where all the code ends up finally. This is the official branch for any project.

Branch gets merged

Now the maintainer of the project has to merge your branch. The maintainer first gets the latest branch contents by doing a bzr pull in the already existing branch on the disk or a bzr branch lp:zeitgeist in case the owner does not have the code with him/her at the moment.

Next the maintainer does a

bzr merge lp:~manishsinha/zeitgeist/testing-branch

which merges both the branches. Next the maintainer commits the changes and pushes the changes in the official branch. The push is done by simply

bzr push lp:zeitgeist

Merge Requests

Launchpad a feature called merge request. When you have your changes ready in a branch present on launchpad, then you can request that your branch be merged with your official branch. The maintainer of the projects gets notified of your request. In the merge request launchpad page, the various maintainers can review your branch changes. Taking their comments into picture, you need to update your branch on the local disk and then push it to the same branch.

An example of the merge request is here


The first line shows who proposed the merge request. There can be cases when a person made the changes and pushed the branch on launchpad, but the merge request was created by someone else.

At the top you can see Status of the merge request which can be
  • Work in Progress
  • Needs Review
  • Approved
  • Rejected
  • Merged

The status are self-explanatory

The next two lines contains
  • Proposed Branch – The branch which needs to be be merged
  • Merged Into – Most of the time it is the official/main branch of the project, but it can be any random branch.

Next you can see who all reviewed the merge request and what they said about it. The review which is used the most are
  • Comment only – Just add a remark
  • Approve – Everything is fine
  • Needs Fixing – Some problems found. It needs to be fixed
  • Needs Information – Sometimes the changes are not clear and the reviewer asks for more information
  • Abstain – The reviewer prefers to abstain from any review
  • Disapprove – The reviewer disagrees with the changes. This is used when the reviewer doesn’t want the changes at all.

Just below you can see the description of the merge request and the various comments from the reviewers. Note that reviewers might not always be the developers of the project you are contributing too. Anyone can be a reviewer in which case Community would be appended to the name in the Review table.

After the comment section you can see the commits which were made in this branch. A person can get the code, make the changes in multiple commits and then push. All the changes which are not in the official branch are shown here.

Below the commit list is the diff. Diff shows the differences of changes. Red lines show what has been removed and green tells what has been added.

Many projects on Launchpad make heavy use of Merge Request. In infrastructures where this feature is not present, bug reports are used for reviews. This feature of Merge Request is more easier for newcomers,much cleaner and clearly separates bugs from merge reviews.


No comments: