4 ms·

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 l

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 9y ago
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 9y ago
  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 9y ago
    How so? Filesystem operations are (or can be) atomic too.
    - vog 9y ago
      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 9y ago
        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-pluggable-backends-libgit2 https://www.perforce.com/blog/your-git-repository-database-p... 2. https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c https://github.com/libgit2/libgit2-backends/blob/master/sqli...
zenhack 9y ago
(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.
geezerjay 9y ago
> 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.

sriku 9y ago

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 9y ago
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 9y ago
  How so? Filesystem operations are (or can be) atomic too.
  - vog 9y ago
    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 9y ago
      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-pluggable-backends-libgit2 https://www.perforce.com/blog/your-git-repository-database-p... 2. https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c https://github.com/libgit2/libgit2-backends/blob/master/sqli...

zenhack 9y ago

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

geezerjay 9y ago

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