Currently Online

Latest Posts

Changes in BzrPrimer

Editor Comment

edited Initial Steps and Getting the Source

Revision Differences of Revision 13

# 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). ¶

[TOC] ¶

## Getting started with bazaar ¶

* Get bazaar: <> or the packaging system of your trust. ¶
* Read [BzrForSVNUsers]( or [BzrForGITUsers]( ¶

## 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. The Windows terminal should work quite similarly, but optionally you can use some kind of GUI like <>. ¶

### Initial Steps ¶

* First install bazaar on your computer. That is the utility used to move files back and forth from Launchpad. ¶

* Start a terminal session on your computer and from the home directory type
in ¶
> `~$ bzr whoami "Your Nam
set \<your.ema\>"` # ification (in case you are using bzr for the first time on this machine): ¶
> `~$ bzr whoami "Your Name \<\>"`

* Then set up a bzr shared-repository folder on your computer by entering ¶
> `~$ bzr init-repo widelands-repo` ¶

>* Now you have ~/widelands-repo directory created. It is empty. If you will be developing media, also set up a repository for the media branch by entering ¶
> `~$ bzr init-repo widelands-media-repo` ¶

>* These repositories will contain trunk and your own branches upporsed to uploading and downloading yonly theur changes. ma

de notoe: '**~$**' there brmeancs homes directory, on linux it tesnd tao be like 'home/johny/'. If unsure where inyou are use 'pwd' or just 'cd' to get to back to heom.e directory. _

### Getting the Source ¶

* To download a "checkout" which is the contents of the __main development trunk__ for the first time,
go to widelands-repo directory: ¶

> `
~$ cd ~/widelands-repo` ¶

* and run: ¶

`~$ bzr branch lp:widelands/trunk` ¶

* When that completes,
create ayou workingll trehave by entering ¶
> `
~$ bzr branch trunk my_/widelands_working_t-ree` ¶
> t
po copy the /trunk/ tpo pulated workingth dwidelands source ctoryde.

Remember: __DO NOT MAKE CHANGES DIRECTLY TO THE TRUNK__. (BAD things happen.) ;( ¶

* To download a "checkout" of the __media trunk__ for the first time,
go to
> `
~$/ cd widelands-media-repo` and run

`~$ bzr branch lp:widelands-media/trunk` ¶
This is a BIG download.)

* When that completes, enter ¶
> `~$ bzr get trunk my_widelands-media_working_tree` ¶
> to copy the trunk to a working directory. __DO NOT MAKE CHANGES DIRECTLY TO THE TRUNK__. (BAD things happen.) ;(

## Getting your changes into the game ¶

### 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, this code will not break mainstream source and anyone can download a specific branch and test it to confirm if it works as expected. Finally when the branch has successfully added the feature or fixed the bug, it will be merged with the main trunk and the 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 a local main branch to pull from upstream and rebase your branches before pushing them back. ¶
(Have we made our point?) ;) ¶

#### To add a new feature ¶
Create a working branch or use an existing "working_tree" ¶

* `$ cd ~/widelands-repo/` ¶
* `$ bzr branch trunk feature-xxx (or my_widelands_working_tree)` ¶

We have created a new branch called feature-xxx that is a copy of the current downloaded (local) main trunk (or branch). We need to move into that folder and make changes there. ¶

* `$ cd ~/widelands-repo/feature-xxx (or $ cd ~/widelands-repo/my_widelands_working_tree)` ¶
* hack with sources or add new media! ¶
* `$ bzr add *` (to alert bzr to any newly added files. If none, this command is optional.) ¶
* `$ bzr commit -m "Feature added: xxx"` ¶

> (It's a good habit to bzr status before committing, to make sure one doesn't forget to bzr add any new files.) ¶

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 needs testing. ¶

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

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

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

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

#### To keep your working tree(s) up to date ¶
with changes others have made on the trunk (or an original personal branch from someone else) you must pull the changes from launchpad and then merge them with your working tree. This is done as follows for the main development trunk. The media trunk and personal branches are handled in a similar fashion: ¶

* `$ cd widelands-repo/trunk` ¶
* `$ bzr pull` ¶
* `$ cd ../my_widelands_working_tree` ¶
* `$ bzr merge ../trunk` ¶
* `$ bzr commit -m "Merged with changes from trunk."` ¶

> __Note__ that any changes you have made to your working tree but have not committed will be lost. So if you wish to keep the work you have done so far in your working tree, do a bzr commit (see above) to first secure them before merging the new changes from the trunk. ¶

### Merging with the main trunk ¶
We have already seen example commands to push our changes to personal branches on launchpad. The typical path for introducing fixes or new features is to first have those changes pushed to a personal branch and then when you feel that branch is ready, submit a proposal for merging on Launchpad. The branch will be flagged as requesting review and merging upon acceptance. ¶

__Experienced members of the development team__ have the ability to merge development branches directly into the main trunk. ¶

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

* `$ cd ~/widelands-repo/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 diverged' 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 local main trunk (see above) and redo the *rebase*, *merge*, *commit* and *push* again. ¶

##### Alternative method ¶
Assuming bug-xxx was originally a branch of the main trunk, __an alternative__ to the rebase is to: ¶

* `$ cd ~/widelands-repo/trunk` ¶
* `$ bzr pull (to get any recent changes to the main trunk)` ¶
* `$ cd ../bug-xxx` ¶
* `$ bzr merge ../trunk` ¶
* `$ bzr commit -m "Merged with changes from main trunk"` ¶
* `$ cd ../trunk` ¶
* `$ bzr merge ../bug-xxx` ¶
* `$ bzr commit -m "Bug xxx fixed"` ¶
* `$ bzr push lp:widelands/trunk` ¶

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 (i.e. your local copy of a trunk or branch) run: ¶

* `$ bzr revert -r <revisionnumber>` ¶

then you are down to that revision number ¶

to get back to HEAD, run: ¶

* `$ bzr revert` ¶
* `$ bzr pull` ¶

### Git-style workspace (lightweight checkouts) ¶

Another way to organize the workspace (and at the same time save some space on your hard disk) is to use the so-called "lightweight checkouts". ¶

Normally, the shared repository (widelands-repo) contains the history of the "common part" of all branches. ¶
A single branch (trunk, feature-xxx, bug-xxx) contains the history of that branch and the current version of _all_ files that are in the branch. ¶

So, if you have 3 branches, you will have 3 times all the unmodified files. ¶

A "lightweight checkout" is simply a "link" to a specific revision of a branch and give you the possibility to keep a single working directory and to attach this working directory to any branch. Since you have only one working directory, you have all files only one time. ¶
In this way it's very similar to git style - a single "moving" workspace (that follow a single branch at time). ¶

In order to use this system, you can generate the branch with the --no-tree option. ¶
This means that the history (and support files) for that branch will be generated, but no actual file belonging to the branch itself is inserted in the branch folder. ¶

* `$ cd ~/widelands-repo/` ¶
* `$ bzr branch --no-tree trunk feature-xxx` ¶

Then you have to create the "working directory" folder and link it to your branch ¶

* `$ cd feature-xxx` ¶
* `$ bzr checkout --lightweight my_widelands_working_tree` ¶
* `$ cd my_widelands_working_tree` ¶

From now on, every time you commit in the "my_widelands_working_tree" folder, you are committing to feature-xxx ¶

Imagine you want to create another branch and start working on it. Here is one way to do it (but see below for a possible shortcut) ¶

* `$ cd ~/widelands-repo/` ¶
* `$ bzr branch --no-tree trunk feature-yyy` ¶

Now we have to "move" our "working directory" so it points to the branch we want to work in. ¶

* `$ cd my_widelands_working_tree` ¶
* `$ bzr switch ../feature-yyy` ¶

now any changed made on my_widelands_working_tree is applied to feature-yyy ¶

NOTE: if you plan to use this approach, you have to type "--no-tree" any time you create a branch. ¶
To avoid this, the initial init-repo command can be modified into ¶

*` $ cd ~` ¶
* `$ bzr init-repo --no-trees widelands-repo` ¶

so that any branch created will be created without trees. Then you can use the `switch` command to create new branches more easily. ¶
Suppose you want to create a branch that starts with the current status of your working directory. You can simply say ¶

* `$ bzr switch -b ../feature-yyy` ¶

to simultaneous create and switch to the new branch. ¶

## Graphical user interfaces for BZR ¶

Among the [BZR Plugins](, there are some nice graphical user interfaces for bzr that can ease the work with bzr (e.g. through showing a commit window where you can select, what you would like to submit, write the commit message and add the number for a fixed bug to the commit) ¶

Available for Linux, Windows and the MAC OS, _qbzr_ is a simple and intuitive user interface, just install qbzr for your repository and afterwards write the same commands on terminal, as before, just with a "q" at the beginning (e.g. "bzr qdiff", "bzr qcommit", ...) ¶

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