Raim

bzr shelve improved in 2.1.0

Rainer Müller — Sat, 27 Feb 2010 01:27:56 +0000

Sometimes I was a bit frustrated that bzr does not support hunk splitting during selection changes with bzr shelve, as does git commit --interactive. Now with bzr 2.1.0 there is a new option available to launch an external editor to shelve changes as you like.

Just add the option change_editor to your ~/.bazaar/bazaar.conf in the [DEFAULT] section.

For example:

[DEFAULT] change_editor = vimdiff -f @new_path @old_path

Alternatively, you can of course use meld or kdiff3 as well as change_editor, which will be a lot easier to use for beginners.

The placeholder @new_path will automatically be replaced with the path of the new version and @old_path with the path of the old version. With this configuration, there will be a new choice “e” during shelve:

... Shelve? [yNefq?]

Entering “e” will start vimdiff in a two column view with the new version to the left and the old version to the right. You should read :help diff in vim to get more information about this mode. Basically you can obtain changes from the other buffer using do (“diff obtain”) and put changes to the other buffer using dp (“diff put”). Note that the old version on the right will be read-only and you are not supposed to change it. Also do not make unrelated changes or introduce new differences as that will result in conflicts on bzr unshelve later.

When you are fine with the changes exit the editor with :wqa. After confirming the shelve once more, you will see the left file as the new version in the working tree and every difference to the right file will be shelved.

Unfortunately this is not yet documented in bzr itself at the time of this writing.

Why I like bzr better than git

Rainer Müller — Tue, 01 Sep 2009 22:20:29 +0000

Many people I know are using git as VCS and like it a lot. Although I used git in the past and still use it from time for time for some open source stuff, I was never a part of the hype on promoting git and bashing bzr.

Instead, after too much struggling with git, I totally turned to bzr now. Why? Now that’s what this post is about.

Supporting multiple workflows

One cannot deny that git is very successful in what it does. But let’s take a look back in the history how git has been started all. At first it has been written as a management tool for the Linux kernel development. The first goal was to create a fast distributed version control system, which was met very early. Back then it was only usable for technical aware people (see the man page, it still calls git the stupid content tracker).

Later on, git has been improved a lot and became easier to use. But what stayed was the Linux centric view of development. Therefore, git has good support for a distributed workflow as it is used in Linux kernel development, but nothing more. So if you want to use git productively in a team you have to adopt this workflow, which is entirely based on a hierarchy of pull operations. The main developer pulls from fellow developers, those again pull from below and so on.

With bzr instead, you have the choice how you want to work. There is more than one workflow and it is possible to use them all. Of course you can do the same with bzr as with git, setting up a pull-based distributed system. But bzr also supports working in centralized ways. You can bind your local branch to another remote branch. Every time you commit, it will automatically be submitted to the bound branch. This is also sometimes called a checkout. A branch contains the full history which will be available for local operations after pulling from remote. Additionally there are lightweight checkouts, where the branch is not in the same location as the checkout and therefore requires access to the branch for almost all operations. But compared with branching a lightweight checkout is a very fast operation and requires less network traffic.

Supporting centralized workflows makes it easier to convert existing projects and infrastructures from CVS/SVN to bzr. There is not much training required for the developers as it works nearly the same as their old system after initial setup.

Each branch has its own tree

As we are talking about workflows this is the next point. A git clone can fetch a lot of different branches. All live in the same directory and if you want to view another one you need to use git checkout . You cannot compare files in branches in a simple way with external tools, you always have to use git diff

(or rather git difftool) which operates on temporary files which means you are unable to edit files right there.


Always seeing only one branch at a time is quite a limited view on the code management infrastructure. Also, if you already made local changes on a branch it might be impossible to switch to another as the changes do not apply there. Therefore you need to hide your changes with git stashbefore switching the branch.
With bzr this is totally different. The main point is that bzr only operates on branches. So you only get one branch when you use the bzr branch command. If you want to also have another branch, use the command again on another branch URL. By default, every branch has its own history storage and associated checkout. If you want to save some disk space, you can create a shared repository with bzr init-repo in the directory which is supposed to hold the branches. If applicable, all branches will share the same storage in this directory.
Having the branches side-by-side makes it a lot easier to compare branches and make edits based on diff reviews. As branches will always be available, you never have to switch between them. Therefore, you do not have to stash changes in bzr  just to view another branch and you will never forget to apply stashed changes after you switched around.
Semantic revision IDs
With git, revisions are identified with a SHA1 checksum. I totally dislike this approach, as it takes all semantics out of the identifier. First of all, the revision id is very long. Yes, you can shorten it to the relevant part only. But still this is not human-readable and cumbersome to type. Bzr just uses incrementing numbers, which is much easier to recognize and remember.
With checksums as revision identifiers you loose any time information. For example if a developer using git tells you, a bug has been fixed in df3b2e, the latest release is f9a4c2 and HEAD is 6ec4b8 you have no idea at all if this revision would be in this release or how long this has been fixed. Now, with bzr this would be: a bug has been fixed in r367, the latest release is r314 and HEAD is r371. So you know immediately that this fix cannot be part of the latest release and is relatively new on the branch.
For more information read on at Understanding revision numbers in the Bazaar User Guide.
Hierarchical history
With git, all your history is flat. If you do a merge you see a message in the log that you did a merge and which HEADs where merged. But you cannot see what exactly has been merged.
Using bzr, merges always create a hierarchy. That means if you work on a feature in a seperate branch and you finally merge it, you will see the merge message in the log, and below that all the commit you did on the other branch. Your history is a hierarchy of changes  This means you have all the changes for this feature grouped together which makes it a lot easier to figure out why a specific commit has been done.
There is also a nice example in the Bazaar User Guide.
Serving a branch is uncomplicated
Did you every try to let others pull from your git branch? Either you need to run git-daemon or run a even more complicated setup using ssh. As a side note, I believe that's why github became so popular, sharing a repository with git is just too difficult to set it up yourself...
With bzr, just drop the branch in your htdocs directory of the webserver and give others a HTTP URL. No special configuration required, no extra daemon. Bzr only needs to transfer regular files for read-only access. Also works the same with FTP. Easy as 1,2,3. But of course you can still run a standalone bzr server or ssh-based setups for better performance and to allow others to write as well.
Plugins and Aliases
One of the most powerful features of bzr is the modularization. Plugins can define new commands and or extend existing commands with new functionality. And there are lots of plugins available, e.g. graphical user interfaces using GTK+ or Qt, import/export to other VCS systems, statistic tools and more. This keeps the main codebase small and clean, but still you can get all the functionality and features you want.
Additionally, you can redefine the meaning of every command in bzr using a simple configuration file. Want always to see the diff in the log message editor? Just add ci = ci --show-diff. You can also add new commands that way. Customize it the way you like so it fits in your workflow.
Library Interfaces
As we talk about custom commands and aliases, we have a main problem of git. The main interface of git is the command line interface. It is used both for user interaction and automation which is why you have to cut back on that and cannot customize it the way you are able with bzr.
As bzr is written in python it offers a module named bzrlib, which can be used for integration into IDEs, Editors and other tools. Bindings for other languages exist as well.
Gun safety
Most important for me is safety of the commands I am executing. With git I got several times to the point where I just deleted the repository to start over. Happened a lot of times as I tried to merge stuff together, as git assumes by default it did the right thing and implicitly commits merges without user review. Maybe I am just not experienced enough with git, but with bzr it is way more harder to shot yourself in the foot.
Conclusion
So much for my experiences and the things I like about bzr. I know that some of you will now comment that I could this and that in various ways with git... But the point for me is: if I obviously couldn't figure out how to do it with git and I had the just works experience with bzr, why should I ever go back?



Hiding MOTD on bash startup
Rainer Müller — Sun, 03 May 2009 16:08:33 +0000
Usually bash displays /etc/motd at the time of last login on opening a new shell. I do not find that information very useful, as I am opening new shells a lot, so the time does not really mean anything for me. Also, the MOTD rarely changes.
There is a feature in bash to hide these messages by creating a file ~/.hushlogin. This will make bash jump right to the first prompt without any output before.
But just in case the MOTD changes and includes important messages, I enhanced this setup a little bit. Instead of just touching the .hushlogin file, I am storing the old MOTD in it. At startup the old and current MOTD is compared against each other and will be displayed only if it differs. To avoid accidentally missing the MOTD, bash will also ask for my confirmation that I have read it.
Here is the snippet from my ~/.bashrc:
# Show motd only if necessary
cmp -s $HOME/.hushlogin /etc/motd
if [ $? != 0 ]; then
    echo -e "\n==> !!! IMPORTANT: /etc/motd changed !!! <==\n"
    cat /etc/motd
    echo -e "\n==> !!! IMPORTANT: /etc/motd changed !!! <==\n"
    read -e -n 1 -p "Show again? (Y/n) " ans
    if [ "$ans" == "n" ]; then
        cat /etc/motd > $HOME/.hushlogin
    fi
fi

Please note: If you are going to use this, make sure it will not get executed on non-interactive shells. Otherwise it can break tools like scp, sftp or rsync. To ensure this will not be used on non-interactive shells, I am using this conditional at the top of my ~/.bashrc:
if [[ $- != *i* ]] ; then
    # Shell is non-interactive.  Be done now!
    return
fi




Subversion diff commands
Rainer Müller — Tue, 17 Mar 2009 10:58:36 +0000
Subversion allows to use a custom command for displaying diffs using svn diff --diff-cmd . I have been using diff-cmd=colordiff in my ~/.subversion/config for quite some time now. This is really useful, but occasionally I would also like to use vimdiff to get a nice side-by-side diff.
Although this sounds quite easy at first, there are some hurdles. Subversion expects the given command to adhere to the GNU diff parameters, that means it expects it to understand and parse the labels it passes before the actual filenames. This works fine for colordiff, but not vimdiff which only wants the old and new filenames.
For a better diff experience with svn, I set up the following shell function which let’s me choose the program I want to use for diffing.
First, I need a new wrapper script at ~/libexec/svndiff which takes the actual diff program as first option, ignores the GNU diff labels and calls that program passing old and new filename.
#!/bin/bash
BIN=$1
shift 5
$BIN "$@"

Then I define this shell alias in my ~/.bashrc to extend the functionality of the svn command:
function svn() {
    case "$1" in
        diff-plain)
            shift;
            `which svn` diff --diff-cmd diff $@
            ;;
        diff-color)
            shift;
            `which svn` diff --diff-cmd colordiff $@
            ;;
        diff-vim)
            shift;
            `which svn` diff --diff-cmd $HOME/libexec/svndiff -x vimdiff $@
            ;;
        diff-filemerge)
            shift;
            `which svn` diff --diff-cmd $HOME/libexec/svndiff -x opendiff $@
            ;;
        *)
            `which svn` $@
            ;;
    esac
}

Now I can choose the program I find best suited for the current task in a very simplified manner, for example svn diff-vim -c1337.



X-Chat Aqua for Mac OS X
Rainer Müller — Wed, 21 Jan 2009 15:14:35 +0000
X-Chat Aqua is a very nice IRC client for Mac OS X, but the latest version for download on their website is way out of date and a few years old.
X-Chat Aqua screenshot
A while ago libc volunteered to import the old CVS into a new SVN repository and started development on it again. So the version in SVN is now based on xchat 2.8.x, but there are still no binaries available.
Therefore I just put together my own build and I am also offering it as a download for everyone. The application bundle contains an Universal binary for both PowerPC and x86, while I was only able to test them on Leopard.
Additionally, I also replaced the default X-Chat icon with a modern one provided by Ryan Fernandez.
Download X-Chat Aqua: xchataqua-2009-01-21.tar.gz



History meme (2)
Rainer Müller — Mon, 09 Jun 2008 20:29:26 +0000
$ history|awk '{print $2}'|sort |uniq -c|sort -rn|head

1134 vim

791 make

516 port

508 svn

305 sudo

283 cd

127 la

124 man

116 wcgrep

103 ./lcs-bottom-up
Some explanations:

lcs-bottom-up is an implementation of LCS I needed for a talk

For other explanations follow the history-meme tag.



History meme
Rainer Müller — Mon, 02 Jun 2008 17:12:37 +0000
As I now have a blog, I can finally take part in the history meme:
$ history|awk '{print $2}'|sort |uniq -c|sort -rn|head

1052 vim

975 make

585 port

444 svn

278 cd

213 sudo

186 man

161 la

120 wcgrep

68 open
Some explanations:

port is MacPorts
la is a shell alias for ‘ls -lA’
wcgrep is a little helper script to grep inside Subversion working copies excluding .svn directories
open is a command in Mac OS X to open a file with the associated application (something similar exists for Linux as xdg-open)

The rest should be clear. I am keeping 5000 commands in my history, so don’t be suprised by the high numbers. The relevant settings from my .bashrc:
export HISTSIZE=5000

export HISTIGNORE="jobs,fg,bg"


I have seen this meme before and the output back then was really different (for example, there is no git in there although I use it occasionally). Maybe I will post this history stuff more often, as it might be interesting how my workflow changes over time. Weekly? See next monday  



Welcome to my personal blog
Rainer Müller — Mon, 02 Jun 2008 16:33:50 +0000
I still don’t have a really good idea what to blog about, but let’s see how it will turn out  
I plan to blog mainly in english, but as my native language is german, I might switch to that from time to time. I am going to categorize posts accordingly whether they are in English or German, so you can easily only get those posts that matter for you. Subscribing to the english or german RSS feed from categories should be enough.
Happy blogging!