Breezy: Forking Bazaar | Hacker News Reader

Breezy: Forking Bazaar

jelmer.uk

77 pointsJoshTriplett15 comments

Bazaar has had a special place in my heart for a while since it was used by the first real Linux flavor I used and written in the first programming language I learned. More practically, it gets right what Git gets wrong about branches: work done on branches and merges of branches into a trunk should be clearly distinct. I use Fossil for my hobby projects now and it also takes a principled stance against editing history. Bazaar did that and also made that unedited history nice to look at. I'm glad bzr is still around in some form and I hope it will step up in the VCS sphere like Firefox has against chrome recently. Monocultures in tech don't lead to better tech.

Same here about fossil. After prolonged exposure to fossil, i tend to get the jitters when I work with git - to the extent that git repos I work with are mirrored into fossil for safe keeping.

From their docs:

> Fossil stores state information in SQLite database files [...] updates are atomic, so even in the event of a system crashes or power failure the repository content is protected.

This is actually a huge improvement over git in terms of data safety.

How so? Filesystem operations are (or can be) atomic too.

Git operations are not atomic, though. This is a huge implementation flaw, if not design flaw.

I had it several times that my laptop (or a VM) crashed during or short after a git commit, before it was fully written from cache to disk. The reasons vary, sometimes the VM disk was full, or some tests ran parallel to the commit that consumed too much RAM.

This doesn't happen often, but every few months. Meanwhile I "solved" this issue by making sure that the system is never in any form "stressed" while I work with Git.

Whatever the reason: The result is a broken Git repository that is so non-trivial to fix, that it was easier to clone it fresh from server and apply the missing changes again from the left-over local file of the broken repo.

You can very easily write a sqlite backend if you want. There are a bunch of interesting ones for libgit2[1][2]

1. https://www.perforce.com/blog/your-git-repository-database-p...

2. https://github.com/libgit2/libgit2-backends/blob/master/sqli...

(Queue semi-weekly flamewar re: modifying history)

It would be nice to see the foss vcs monoculture shaken up a bit. There are lots of neat tools out there (fossil is pretty cool), but having an established workflow and a ton of users is worth so much for a collaborative tool.

> work done on branches and merges of branches into a trunk should be clearly distinct.

In git these are distinct if the workflow requires the. To be distinct. If the workflow doesn't require forks and merges to be distinct, they don't need to be.

I still use Bazaar for personal projects and sometimes as a frontend for Git repositories.

Things that Bazaar got right that I find missing from most other DVCSes:

- Branches (including remote branches) are first-class citizens. I can add and remove tags for remote repositories as though they were local, I can diff against and merge from remote branches, I can view a log for remote branches. It gives me most of the essential GitHub functionality on the command line.

- It accomplishes that by properly abstracting over the transport layer. This also means that you can use any computer that you can use ssh with for remote repositories/branches via the `sftp` protocol without having to install Bazaar on that machine. While this is not recommended for large projects, it makes it pretty easy to share and collaborate on your projects if you have some old server lying around (e.g. in an academic setting).

- Unlike most other DVCSes (except Fossil), Bazaar put some thought into how to present revision graphs to users; rather than dumping the raw graph, it uses hierarchical logs, which I find generally more intuitive.

- A particular benefit is that there's generally no need for rebasing; while Bazaar has a rebase plugin, you can generally avoid rebasing, as linearizing history is unnecessary (and arguably counterproductive).

- Another side effect of hierarchical logs is that there's an intuitive canonical revision numbering scheme. You don't need hashes, any revision is uniquely and globally consistently identified by the pair (branch, revision number). This also makes `bzr annotate` more readable.

Downsides of Bazaar:

- Bazaar didn't have the development efforts put into it that Git and Mercurial got, so it still has some rough edges for advanced use cases. For example, if you do `bzr uncommit`, `bzr commit` does not give you the option to reuse the commit message (even though it's saved and the GUI version of commit will properly prepopulate the commit message box).

- Customization is cumbersome, and generally requires writing a plugin rather than templating (unlike, say, Mercurial, which has superior customization options).

- Like Git (though for different reasons), Bazaar requires you to periodically repack your repository, and for large repositories with a long history that can take a fair amount of time. For example, the Dart SDK repository (50k+ commits, 17MB checkout) can take several minutes to repack. While this is infrequent (I think the really expensive repacks occur only every 10k commits or so), when they happen, it's a pain.

Bazaar was my first DVCS and I was a holdout against using Git for many years since I was so used to using bzr in the open source world. A few weeks ago I realized my email has been subscribed to the mailing list for 13 years now and I decided to take a look and it's a bit chaotic!

I miss the command-line interface of Bazaar, and the fact that you can undo reverting any changes to a file. The equivalent in Git (`git checkout -- filename`) is impossible to undo. I'm still going to use Git, it's a really great tool once you climb the learning curve.

Why did Bazaar fall away? It just seemed like once git came along (more specifically, github) everyone ditched their already existing infrastructure and jumped on git.

It was slower than git, used more disk space and hence downloading from remote took longer, didn't allow in-place branching (you had to change directory), no history re-writing and didn't have the staging area in the same way.

They tackled some of these issues but by then they had a reputation and a lot of projects had switched to git - Linux gave it a lot of momentum.

Why should anyone use it if they readily admit you should use Git instead? That seems like a pretty negative commentary to start the introduction off to your project.

As mentioned in the post:

> the main goal is to keep Bazaar usable going forward.

If you don't need to run Bazaar, you don't need to use Breezy, and it has no real use for you.

Reply on news.ycombinator.com