
Breezy: Forking Bazaar - JoshTriplett
https://www.jelmer.uk/breezy-intro.html#
======
jaccarmac
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.

~~~
sriku
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.

~~~
vog
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.

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

~~~
vog
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.

~~~
orf
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...](https://www.perforce.com/blog/your-git-repository-database-
pluggable-backends-libgit2)

2\.
[https://github.com/libgit2/libgit2-backends/blob/master/sqli...](https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c)

------
rbehrends
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.

------
krisives
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!

------
Flimm
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.

------
noobermin
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.

~~~
desas
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.

------
moonshinefe
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.

~~~
jorams
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.

