Bazaar-NG: Seven years of hacking on a distributed version control system (2012) | Hacker News Reader

Bazaar-NG: Seven years of hacking on a distributed version control system (2012)

stationary-traveller.eu

47 pointssigna117 comments

One thing I took away from this article is that "the concept was promising, the implementation too slow and cumbersome in practice" so the author stuck around to improve it. Bzr is still, many years later, interesting, slow and cumbersome.

I that tends to be so because once your data structure are set in stone, the complexity of the implementation follows. You can always work to improve performance, but without redesigning your basic concepts you'll only go so far.

There are similarities in other areas than theoretic complexity models. I tried a phone a while ago. It waws promising but the UI was far from smooth. The person I spoke with insisted that it's a first version and performance will surely improve. But if your basic drawing primitives isn't smooth by design, your final version will never be. The comparison is far from perfect of course, but provides food for my thoughts.

I'm not so sure about this. When the JVM first came out, it was slow as hell; by your logic, this was an indication of a design flaw which would plague the JVM forever. Well, the JVM is blazing fast now. They worked around most inefficiencies. Facebook was built on PHP and MySQL (remarkably slow technologies), yet they scaled this to one of the largest systems which ever existed.

If an UI is slow, surely you can find a more efficient way to draw the elements on the screen, or to reduce their resource consumption, or just give the UI better hardware.

You can always optimize. Some design decisions make this hard, but I think you can always work around them.

I loved bzr and I still think it should had become the current default vcs.

The killer feature of bzr for me is that it is just a nice interface in front of a dozen different VCS data structures. Some of these were worse than the only one supported by git, others were much better.

What made me switch from bzr to git around 2011 is:

* slowness compared to git. I have `git status` in my command prompt, it takes a split second. I could not have `bzr status` in my command prompt: it took it about 2 seconds for it to complete. This is mostly due to it being written in Python: the startup time is just too big.

* inability to rewrite history. bzr almost forces you to see "how the sausages are done". There are many pros to this approach, but I could not stand having to go through a complex pipeline system just to fix a typo in a certain commit message or reorder two completely independent commits. I moved to git after the first time I run `git rebase -i`.

* The horrible Canonical appropriation. I was fine with the CLA imposed by Canonical on bzr but I could not stand the announcement that bzr was moving from http://bazaar-vcs.org/ to http://bazaar.canonical.com/ [1]. The move itself was unpleasant but the following quote really got on my nerves:

> Canonical wants to more clearly show its support for Bazaar, while still recognizing that Bazaar is more than just Canonical and has its own community.

The way you recognize Bazaar is more than just Canonical is to move from a generic domain to canonical.com subdomain? OK, bye.

[1] https://lists.ubuntu.com/archives/bazaar/2009q4/063183.html

We lost sight of what mattered for our users, focusing on features that were nice but perhaps not as necessary as we thought. We overengineered. We didn't get rid of the crufty unnecessary features.

I learned an awful lot. Time for something new.

I was wondering because the post seemed to be so familiar. Turns out it is from 2012.

Yeah, sites that don't post dates on their articles really bug me.

I've spent about 3 hours reading it. I don't want to know how long it took the author to write that. But it is great to see the history of dvcs from Bazaars point of view for a change. Very interesting read.

Reply on news.ycombinator.com