Latest Posts

Changes in BzrPrimer

Editor Comment

Add bzr whoami as a Getting Started step

Revision Differences of Revision 4

# Bazaar primer for SVN developers ¶

This will explain in a shortened workflow how to make the steps from having developed on and knowing SVN to developing on []( using bazaar (bzr). ¶

## Getting started with bazaar ¶

* Get bazaar: <> or the packaging system of your trust. ¶
* Read <>. ¶

## Getting started with launchpad ¶

* Get an account: <> ¶
* Register an SSH key with your account: <>, interesting read is also <> ¶

## Getting started with widelands development ¶

This is for unixes. Windows should work quite similar, but obviously using some kind of GUI like <>. ¶

~~~~~~ ¶
bzr whoami "Your Name <>" # if you are using bzr for the first time on this machine ¶
mkdir widelands && cd widelands ¶
$ bzr init-repo . ¶
$ bzr get lp:widelands # This will fetch widelands trunk. ¶
$ cd widelands ¶
hack hack hack ¶
$ bzr commit -m "Commit of a very cool new feature I contributed" ¶
~~~~~~ ¶

The next step varies. If you are a member of [widelands-dev]( you can directly get your changes back to launchpad: ¶
~~~~~~ ¶
$ bzr push lp:~widelands-dev/widelands/trunk # see the --remember option ¶
~~~~~~ ¶

If you are not a member of [widelands-dev](, you can still push your changes up to launchpad: ¶
~~~~~~ ¶
$ bzr push lp:~myusername/widelands/cool-new-feature-branch ¶
~~~~~~ ¶

--- ¶

## The way I work ¶
I will explain briefly how I will work with bazaar. I have some experience with git that is pretty like bazaar. ¶

### To download main stream ¶
The code will be downloaded to ~/widelands ¶

* $ cd ~ ¶
* $ bzr branch lp:widelands ¶
* $ cd widelands ¶

### To get changes on main branch ¶
When someone push or merges changes to main branch, you need to update your sources. ¶

* $ cd ~/widelands/ ¶
* $ bzr pull ¶

### Branches ¶
The strong points of distributed version controls are the freedom to create branches for every single feature to add or bug to be fixed. While developing, his code will not break mainstream source. And anyone can download a specific branch and test it to confirm if works as spected. Finally when branch has added the feature or fixed the bug, it will be merged with mainstream and branch can be deleted safely. ¶
Another strong point of working only on branches is the lower risk of conflicts when merging. My recommendation is only work on branches, and use local main branch to pull from upstream and rebase your branches before pushing back. ¶

#### To add a new feature ¶

* $ cd ~/widelands/ ¶
* $ bzr branch widelands feature-xxx ¶

We have created a new branch called feature-xxx that is a copy of current downloaded mainstream branch. We need to move onto them and make changes there. ¶

* $ cd ~/widelands/feature-xxx ¶
* hack with sources! ¶
* $ bzr commit -m "Feature added: xxx" ¶

We now push changes to our own personal repo. ¶

* $ bzr push ¶

Now we can send a mail to inform other devs and players that branch my-feature-xxx need testing. ¶

If you need to fix something or people report some problem with branch: ¶

* $ cd ~/widelands/feature-xxx ¶
* make more hacks! ¶
* $ bzr commit -m "Bug fixed on feature xxx" ¶
* $ bzr push ¶

#### To fix a bug ¶
You can work on mainstream or create a new branch only for fixing it, to avoid breaking mainstream. I prefer create a new branch and merge it with mainstream when confirmed that bug is fixed. The way to work is exactly like to add new feature. ¶

* $ cd ~/widelands/ ¶
* $ bzr branch widelands bug-xxx <- This creates my branch to hack ¶
* $ cd bug-xxx ¶
* hack to solve bug ¶
* $ bzr commit -m "Bug xxx fixed" ¶
* $ bzr push ¶

#### To upload changes to mainstream manually (not recommended) ¶
When bug get fully fixed or feature added really work without problems, then you can propose a merge with main through launchpad web. Or rebase your bug-xxx branch with mainstream, merge bug-xxx with main and do a push on main. Note: If you do this way you need rebase plugin for bazaar. ¶

* $ cd ~/widelands/bug-xxx ¶
* $ bzr rebase ~/widelands ¶

Now we merge our local branch with our local mainstream. ¶

* $ cd ~/widelands ¶
* $ bzr merge bug-xxx ¶
* Solve conflicts with merges ¶

Some test are needed, at least try to build! ¶
When you were sure that all is ok, you can upload to mainstream. ¶
Note: After a merge allways a commit is needed. ¶

* $ bzr commit -m "Merged with bug-xxx" ¶
* $ bzr push ¶

Doing that way another developer can push a change before you push yours, in this case a conflict could arise when try to push, 'branches has diversed' or something like. When this happens you simply uncommit your merges to main: ¶

* $ cd ~/widelands ¶
* $ bzr uncommit ¶

Revert to undo merge: ¶

* $ bzr revert ¶

Update your mainstream (see above) and redo the *rebase*, *merge*, *commit* and *push* again. ¶

Doing manually can be a bit 'time consuming' if a lot of developers push at same time so **I think that is better to make a petition to merge and solve all on launchpad web**. ¶

### Getting a specific revision ¶

In your bzr checkout run: ¶

* $ bzr revert -r <revisionnumber> ¶

than you are down to that revision number ¶

to get back to HEAD, run: ¶

* $ bzr revert ¶
* $ bzr pull ¶

--- ¶
Now, speak up on the [mailinglist widelands-public]( and we might merge your branch into trunk if it is good. ¶