Open Stack

2011/4/21 Vishvananda Ishaya <vishvananda at gmail.com>:
> This right here is my main issue with bzr.  I can handle the slowness,

Slight change of topic. What exactly is it that you guys find so slow
that you actually feel the need to complain about it? I can't help but
wonder if there's something different in the way we use bzr that makes
it feel slow for you and not for me, because I'm really not getting
it. I'm not trying to devalue your opinions, I'm just trying to
understand them, otherwise this discussion will never, ever be
productive.

For giggles (and to actually have some numbers that we can relate to)
I tried using bzr to work on the linux kernel for a little bit. That's
a pretty massive body of history as well as code. While I could
*measure* the difference (after all, these computer things can measure
stuff with pretty decent resolution), it didn't really *feel* much
different.

All of these were done with a cold cache:

It took 13.5 seconds to run "git diff".
It took 15.2 seconds to run "bzr diff".
Committing a one-line change with "git commit -a -m foo" took 15.8 seconds.
Committing a one-line change with "bzr commit -m foo" took 16.3 seconds.
Committing a one-line change with "git commit -m foo <filename>" took
15.8 seconds. (Not kidding!)
Committing a one-line change with "git add <filename>; git commit -m
foo" took 0.5 seconds.
Committing a one-line change with "bzr commit -m foo <filename>" took
1.5 seconds.

Yes, it's consistently slower (except that odd-ball "git commit -m foo
<filename>" thing which I ran 3 times extra to make sure), but not
nearly enough that I'd spend time complaining about it. If I want to
commit something and don't set a commit message on the command line,
the majority of the time will be spent in a text editor typing a
commit message anyway. If I specify a commit message on the command
line, it's only when I want to push my changes that I need to wait for
it to finish. If I'm just committing stuff to snapshot my current work
in progress, I just run "bzr commit -m foo" and alt-tab my way back to
my editor.

Please help me understand either:

* how these small differences end up having a large impact (like, say,
which part of your workflow gets interrupted by it on a regular basis)

or

* what you're doing that is actually much slower. I'll readily admit
that my analysis further up was crude and by no means at all
comprehensive. I didn't feel the need to do 50 different things to
measure the exact difference, since I have a hunch that you guys will
have examples readily available that can explain and help me
understand better.


> but I find it very difficult to maintain multiple branches and share patches between them in bzr.  I end up doing a lot of diff | patch -p0.  I think git's rebase is far superior to that workflow.  I'll take a look at loom, sounds interesting.

This sounds fascinating. I can't remember having to do anything like
this. Can you give me an example?

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/