5 ms·
Breezy Version Control System
- ptx 3y agoIs this a fork of Bazaar? The docs have a Canonical copyright notice and the Administrator's Guide starts with "Welcome to the Bazaar Version Control System’s guide".
- krylon 3y agoIt says it is written in Python. Wasn't bazaar written in Haskell or OCaml?
- dec0dedab0de 3y agobazaar is python
- alhadrad 3y agoHackable also... Yikes! Version control is inherently an archival system. Having a hackable VCS system seems like a good way to lose data.
- vore 3y agoYou've heard of security through obscurity, now it's time for... data integrity through obscurity...?
- PuercoPop 3y agoYou are thinking of darcs, that is the one that was written in Haskell. Although Darcs is more related to pijul than to git
- tlavoie 3y agoYou might be thinking of Darcs, which is written in Haskell.
- l72 3y agoCorrect, this is the continuation of Bazaar.
- maxerickson 3y agoWikipedia has a potentially useful sentence: https://en.wikipedia.org/wiki/GNU_Bazaar#Breezy https://en.wikipedia.org/wiki/GNU_Bazaar#Breezy Bazaar was forked as Breezy in 2017 to allow backwards-incompatible changes to be made, such as migrating from Python 2 to Python 3 and dropping support for older versions of Windows.
- charcircuit 3y agoThis website does a bad job of selling itself compared to other VCS. It tells you to check the wiki, but the wiki is empty and mentions the Bazaar wiki. But if you search for the Bazaar wiki you won't find it because it is offline. So you have to figure out it's URL then go to the wayback machine. When going to the wiki via the wayback machine the articles comparing it to mercurial and git are not linked on the main page.
- refulgentis 3y agoAny context OP? This looks relatively old, so I assume the context isn't recent new. Beyond that, there's not much clarity on the landing page other than A) VCS B) uses both Git and Bazaar binary formats* * which is bizarre, pun intended
- ur-whale 3y agoNotably missing from the docs is a "Why?" Specifically, in what way is Breezy an improvement over existing DVCSes
- deleted 3y ago[deleted]
- Jaxan 3y agoNote that it says copyright 2013 on the bottom. So it is one of the existing DVCSes. Still I agree that the page doesn’t show much.
- actionfromafar 3y agoThe original answer must have been, beats CVS handsomely.
- sampo 3y agoBazaar (and probably Breezy also) is able to push over ssh or sftp into the remote file system without needing Bazaar to be installed on the remote computer. Whereas with git and mercurial you need to have git or mercurial installed on the remote computer as well. This is probably not at all important today, but things were different 17 years ago.
- plorkyeran 3y agoGit does not need git to be installed on the remote system to push or pull over ssh.
- sampo 3y agoAccording to this 2011 Stackoverflow answer, the remote machine needs to have `git-receive-pack` available. If not the whole of git. https://stackoverflow.com/questions/5533912/what-is-a-simple-way-to-git-push-to-another-machine https://stackoverflow.com/questions/5533912/what-is-a-simple...
- cmrdporcupine 3y ago
- spicybright 3y agoI read the "breezy in 5 minutes" article but it didn't really explain much. Almost all the commands were exactly the same in git, and the console output looked the same as git. So what's the point? Is it just for people to hack on?
- a1o 3y agoThis is the fork of GNU Bazaar which is from 2005, before git was a thing.
- l72 3y agoWhen moving from subversion to a DVCS around 2006, we evaluated git, bazaar (now breezy), and mercurial. This was before github, and git was really tied to the development style of the linux kernel. I can't remember exactly what issues we had with mercurial, but everyone in the group loved bazaar. It has a very simple and easy to understand model. It was comfortable to those used to a more centralized style (like csv/svn), but gave you offline commits/history, branching, excellent merging, and good tools to look at history. All developers needed to know where: checkout, pull, commit, push, diff, log, and merge. It worked on _all_ platforms, new people to version control never struggled with it, and tools like Tortoise and Trac supported it. There was no confusion about remotes, detached heads, or anything like that. Unfortunately, by 2010-2012, it was clear that git was going to be the winner, and our younger developers wanted to use it and github. We did eventually migrate all projects to git. I still have some personal projects that I use breezy with, although, all new projects I use git now. One of my favorite aspects is how it shows history and merging. `bzr log` only shows commits directly on that branch. So if you are looking at the master branch that has commits A, B, and C, if someone goes off and works on D and makes commits D1, D2, D3, when D is merged into master, you now just see A -> B -> C -> D, where D is everything from D1+D2+D3. You can off course break down D into its sub-commits (and sub-merges, like when you merge master back into a branch), but as a default, this leads to a really clean history. No arguments over squashing / rebasing / FF-only / merge-commits, etc.
- ptx 3y ago> `bzr log` only shows commits directly on that branch. So if you are looking at the master branch that has commits A, B, and C, if someone goes off and works on D and makes commits D1, D2, D3, when D is merged into master, you now just see A -> B -> C -> D, where D is everything from D1+D2+D3. I think Git supports this with "git log --first-parent", to show only the merge commit, doesn't it? That's what I gathered from a discussion here some time ago on branching strategies.
- gizmo 3y agoNot being quite sure how git deals with this even though, as the parent argues, it is the sensible default behavior, is really the problem. Everything is possible with git but nothing is easy or easy to remember.