Marcin Juszkiewicz - scm

Bazaar — what is wrong with it?

2010-10-06T16:24:00+02:00

Each time when I have to use Bazaar I feel sick. It takes hours to do things which should not take more then few minutes. Let’s start with today problem and compare it to git.

I finally got armel-cross-toolchain-base to build with non-sysrooted binutils. It required adding one patch and building binutils twice (once with sysroot for use during build, second without to put it in Ubuntu archive). After whole work I had 2 files to add, 3 hunks of changes in debian/rules and that’s all.

So I used “bzr add” on new files and “bzr commit -i” to select which hunks goes into which commit and repeated it until all changes landed in local branch. But then I discovered that I forgot to add 1.51 version into debian/changelog file before whole that work. So I did it now and next commit added 1.52 version.

And this is when whole “fun” started… I wanted to move r131 (the one with 1.51 changelog entry) to be before r128 one. With git it is just a matter or “git rebase -i” and whole work is done. But this was bzr…

“bzr rebase” command (part of “bzr-rewrite” package) supports only rebasing on top of other branch. But it was also useful as my branch was a bit out of sync with upstream one. So I started to ask questions on #linaro channel as Zygmunt was there and his knowledge of Bazaar was a big help in past. There were few ideas and I did some reading in meanwhile.

One solution was “use pipelines” and you know? They even works but then I needed to cherry pick one commit (r131 one). The only way which I found was “bzr merge -r130..131 :first” and I got all changes but not changeset. Right, git users, you have to commit after merge (and use “bzr log” to find commit message). And when you try “bzr merge” for few revisions they will be squashed… So finally what I did was merging changeset by changeset and commiting with original commit messages. Good that it was just few of them.

So after more then 10 minutes (“git rebase -i”) I finally got branch ready to be pushed. Next time I will spend that time on checking what is wrong with git-bzr-ng plugin as this will give me working two-way handling of Bazaar repositories without touching “bzr” command.

GIT - second try

2008-03-20T16:11:00+01:00

Due to recent discussion on OpenEmbedded mailing list I decided to give GIT second chance (first one was few months ago).

I imported Poky using git-svn tool and started hacking. First work was switching to OPKG (described in other post). I created branch for it and changed bit after bit — result was patchset with 17 patches. I pushed them into official Subversion repository in a bit other order and as few less revisions. After that I dropped branch as not needed any more.

Next was creating few branches for local hacks. Merging branches is easy when there are no conflicts and require manual calling of git mergetool FILE (instead of that being called automatically). Cherry picker works very nice and “rebasing” branches recognize such revisions.

Nasty thing is that every change has to be committed before switching branches as there is only one “working copy” at time (not like in CVS, Subversion or Monotone where you need “working copy” per branch).

What do I feel about GIT now? I started to like it.

GIT and I do not match

2007-11-14T20:17:00+01:00

For both of my desktop machines I use git kernels and from time to time I add some additional patches to get something experimental to test. By default I use “quilt” to manage patches so my usual kernel session looks like:

quilt pop -a
git pull
quilt push -a

And as a result I have updated kernel with all my patches applied. If one of them do not apply I usually do updating by hand and call quilt refresh or search for newer version of patch.

Today I decided to do another attempt to use just GIT for managing my patched kernel tree instead of using GIT + quilt. And I failed :(

I cannot understand why GIT developers say that they hate CVS but follow its way when it comes to merging stuff… If any operation ends in merge conflicts all you get is file with CVS conflict markers inside. You need to call merge tool by hand, resolve problem, add files back to repository (do not ask me why adding files already known to SCM is needed) and tell that you resolved conflict. Even CVS or Subversion does not works that way…

I like the way it works with monotone — if there is conflict during update (so git pull like) merge tool is called (kdiff3 on my system) and user has to resolve all conflicts before monotone will go into next step. Whole merging stuff is then stored as another revision (with git it can be then remove during git rebase).

Maybe one day I will find a way to get familiar with git but it is not today…

I really don’t like CVS

2005-10-12T22:53:00+02:00

After using BitKeeper (when it has free license), Subversion and monotone each time when I have to work with CVS repository I feel sick. Simple operations takes time — comparing changes need contact with remote repository which sucks especially with SourceForge CVS service (avoid if you can).

But sometimes there is no other choice ;(