Bazaar on the slow track [LWN.net]

By Jonathan Corbet
September 11, 2012

The Bazaar (or "bzr") version control system lacks the visibility of systems like Git or even Mercurial. That is not to say that it is an insignificant project: it has a dedicated following of its own, it is the system used internally at Canonical, and it has been designated as an official GNU project (meaning that other GNU projects are expected to use it). So one would not think that Bazaar was a project in danger of running out of steam and grinding to a halt. But that, it seems, is exactly the scenario that some of its users are worried about.

Stefan Monnier kicked off the discussion by noting that the number of commits to Bazaar has been dropping and that bugs are not getting fixed. The departure of lead developer Martin Pool from Canonical (and from the Bazaar project) has certainly not helped the situation. So, Stefan said:

[A]s unfixed bugs accumulate, I'm beginning to feel a bit like in the bad CVS days where you just had to get used to circumventing its limitations, for lack of actual development.

Some participants questioned whether there was a problem, noting that commits continue to flow into the Bazaar repository. But Matthew Fuller ran the numbers and came to a fairly clear conclusion:

From even a casual glance, falloff in bzr.dev landings is pretty obvious. Through most of the history (looking at the month level), bzr.dev averages at least a rev a day, not uncommonly twice that. But the last 5 months put together don't even reach the single month average. It's no proof of development stopping by any means, but it sure is a red flag likely to lead people to that conclusion.

This slowdown has happened despite the fact that a new major release (2.6) was expected in August. When that release does happen, the list of new features seems unlikely to knock the socks off many users. Bazaar, as a project, may not be dead, but it shows signs of going into a sort of maintenance mode.

What is going on?

Once one accepts that development on Bazaar is slowing, it is natural to wonder why that is and what can be done about it. One possibility is that the distributed version control problem has been solved and that there is little need for more development. After all, significant projects like bash and make have not shown blistering rates of development; there simply is no need at this point. In the distributed version control system area, though, it would be hard to say that there are no challenges remaining. Projects like Git and Mercurial continue to evolve at a high rate. So, in a general sense, it would be hard to say that Bazaar is slowing down because there's nothing more to do.

That doesn't mean that Canonical, which has sponsored most of the work on Bazaar, sees more that needs to be done. Indeed, according to John Arbash Meinel (Martin Pool's replacement as Bazaar lead developer), Canonical is happy with the current state of affairs:

I think fundamentally Bazaar does most of what Canonical needs, and the team has been focusing more on other bits around Bazaar (Launchpad, package-importer, bzr-svn integration, etc). Also, Launchpad and Bazaar have never really been meant as products in their own right, but more as facilities to build Ubuntu. And while not perfect, they do a pretty darn good job of it, and it makes sense to focus more on other areas of development.

He added that Bazaar wasn't in danger of disappearing anytime soon. "It is still being actively maintained, though a little less actively than last year." That statement was seen by some as an oblique way of saying that Bazaar is now in maintenance mode — a prospect that was not seen as particularly reassuring by Bazaar users.

Of course, Bazaar is free software, licensed under the GPL, so anybody is free to step up and carry it forward. Thus far, though, that has not happened. Once again, it is worthwhile to think about why that might be. Possibly Bazaar users got comfortable with Canonical carrying the load of Bazaar development and have not, yet, felt the need to help out. Over time, some of these users might decide that it is time to pick up some of that load going forward. Or they might just switch to another system with a more active community.

One possibility, raised by Ben Finney, is that Canonical's much-maligned contributor agreement is a part of the problem. This reasoning says that, since Canonical reserves the right to release contributions to Bazaar under proprietary licenses, many potential contributors have voted with their feet and gone elsewhere. It's far from clear that the contributor agreement is really part of the problem, though. If there were really a community of developers who would contribute if only the terms were more fair, an agreement-less Bazaar fork would almost certainly have emerged by now. The fact that nobody has even attempted such a fork suggests that Canonical's agreement is not really holding things back.

Stephen Turnbull had an interesting alternative explanation for what is going on. Bazaar, he says, is a tool aimed at users who want their version control system to "just work" without them having to think about it much. Git, he says, is a different matter:

Many of those who chose git also made a deliberate, informed choice, knowing that use of git requires both an investment in learning about the tool and, often, day-to-day thought about workflow. My suggestion is that such people are on average more likely to contribute to git than the average bzr user is to contribute to Bazaar.

Some participants saw this suggestion as a sort of insult against Bazaar users, saying that they lacked the ability or the drive to improve the tool. But that is not what Stephen was saying; his point is that, by appealing to users who don't want to have to think about their version control system, Bazaar has created a user community that is relatively unlikely to want to put their time into making the system better.

There is an alternative that nobody has mentioned in this discussion: perhaps Bazaar has simply lost out to competing projects which have managed to advance further and faster. For sheer functionality, Git is hard to compete with. For those who are put off by the complexity of Git, Mercurial offers a gentler alternative without compromising on features. Perhaps most potential users just do not see anything in Bazaar that is sufficiently shiny to attract them away from the other tools.

If that is the case, it is hard to imagine what can be done to improve the situation from the point of view of Bazaar users, especially given that Canonical has lost interest in adding features to Bazaar. Perhaps, as Ben suggested, another corporate sponsor could be found to take up the Bazaar banner. Failing that, Bazaar seems likely to stay in maintenance mode indefinitely; it will remain a capable tool, but will find itself increasingly left behind by the other free alternatives.

to post comments

Bazaar on the slow track

Posted Sep 11, 2012 21:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

Another point - bzr has a very confusing model. It's a DVCS for projects with the central 'trunk'.

Git is conceptually simple (it's just a list of hash-linked diffs between revisions). Mercurial is more complicated (it tracks tree changes) but by now it's not really that different from git in functionality.

Bzr stands out among them. And for reasons that are not really clear.

Bazaar on the slow track

Posted Sep 11, 2012 21:42 UTC (Tue) by juliank (guest, #45896) [Link] (5 responses)

It supports automatically pushing stuff on commit, but that's not really required or needed. You can just use bzr branch instead of bzr checkout to create a branch that is disconnected from the parent one.

Bazaar just adopted common terminology: checkout works the same way as in svn, branch (aka get/clone, but those are deprecated) works like clone in git.

Bazaar on the slow track

Posted Sep 11, 2012 22:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

No, I'm talking about the way it does versioning. There is no clear way to unambiguously refer to a commit, because version numbers are repository-dependent and are clearly designed with the idea of the 'central' repository.

For example: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/hea...
You see that this file has revision 6558. This version is repository-local as there's no way to create a distributed numbering algorithm without synchronization points (mathematically, bzr revisions are a completely ordered set). This fact underlines all the bzr design - it's ridiculously hard to work in a truly distributed manner with bzr. There's even that scary threat of renumbering, where numbers in the trunk _change_.

In comparison, hg and git are truly distributed - they're using hashes to identify commits: http://selenic.com/repo/hg/rev/8fea378242e3 This design makes sure that there's no single global ordering of commits, but there is always a clearly-defined local ordering (i.e. git/hg commits form a partially ordered set).

Bazaar on the slow track

Posted Sep 11, 2012 22:23 UTC (Tue) by james_w (guest, #51167) [Link] (1 responses)

Click "View revision" and you will find the unique id of that revision: pqm@pqm.ubuntu.com-20120905205226-8s3bzolvduug3ifj. That id will never change. The revision numbers are just for convenience when you know the context you are talking about. If you don't know the context then use the ids.

Bazaar on the slow track

Posted Sep 11, 2012 22:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Yet almost all bzr tools insist on working and showing revision numbers, rather than the unwieldy global IDs. There are lots more of smaller annoyances in bzr that are simply not present in git/hg.

For instance, try to google your ID - it's not present in any publically-crawled repository viewers.

Bazaar on the slow track

Posted Sep 11, 2012 23:10 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

I've used CVS and SVN extensively. I've used git extensively. And also a few others from time to time. In theory this should give me plenty enough background to easily understand Bazaar's data model(s), shouldn't it? Yet not. The few times I tried to run a few basic Bazaar commands I got completely confused by this very strange mix of centralized AND distributed models. Or by other things? I guess I'll never know.

I much prefer a simple, clear and sound data model over a familiar and supposedly "user-friendly" interface.

On the other hand I've met a significant number of people who want to know as little as possible about version control *in general* (I know this is wrong but what can you do?). They just want to run the same and very small subset of commands again and again to publish their work without absolutely any interest for what happens behind the scenes nor for any other actual version control feature. git's complex and inconsistency command line makes their life extremely difficult. They would probably much prefer Bazaar. As noted in the article, this type of lusers would also be extremely unlikely to contribute to any VC tool in any way.

Great quote: "A common response I get to complaints about Git’s command line complexity is that “you don’t need to use all those commands, you can use it like Subversion if that’s what you really want”. Rubbish. That’s like telling an old granny that the freeway isn’t scary, she can drive at 20kph in the left lane if she wants."
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-...

Sometimes I wish I weren't that comfortable with git because that makes me too lazy now to try and learn Mercurial...

Bazaar on the slow track

Posted Sep 12, 2012 2:33 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> Sometimes I wish I weren't that comfortable with git because that makes me too lazy now to try and learn Mercurial...

I tried using it for a few hours and my git experience made me lose some changes[1]. I'd call it data loss, but the devs consider it just a bug. Sure, they're both a DVCS, but I think starting from step one is probably easier when learning a new one than trying to make analogies based on my experience with darcs (XMonad repos and some other Haskell stuff), hg (tried to make a patch for mutt and udiskie), and one attempt to do something with bzr (don't even remember what it was, but zsh's vcs_info plugin for it is/was molasses (as in 5s for a prompt to appear with just the branch name and "dirty" status)). Every time, I get the feeling "I'd rather use git", but that's probably just familiarity talking.

[1]http://bz.selenic.com/show_bug.cgi?id=3423

Bazaar on the slow track

Posted Sep 11, 2012 23:32 UTC (Tue) by nix (subscriber, #2304) [Link]

it's just a list of hash-linked diffs between revisions

ITYM 'it's just a parent-linked tree of filesystem tree snapshots in a content-addressable store'.

(Sure, the *pack implementation* happens to be delta-compressed, but one of git's very nice features, shared with bzr as it happens, is that this is not visible to the user at all: the conceptual model and the storage mechanism are completely decoupled. Recently-added (loose) objects, note, are gzipped but not delta-compressed at all, but the user need not care.)

Bazaar on the slow track

Posted Sep 13, 2012 7:51 UTC (Thu) by mbp (subscriber, #2737) [Link] (4 responses)

bzr's model is a DAG with special emphasis given to the path from the branch tip back to the origin through left-hand ancestors. It's quite mathematical and not that hard to understand.

In many projects, after a patch/feature/fix is merged to trunk, the history of just how that patch was written becomes relatively unimportant: to start with, people looking at history just want to see "jdoe fixed bug 123". One approach is to literally throw that history away and just submit a plain patch, as is often done with git. I wanted to try something different that would keep all the history, but also have a view of which path through the dag was the main history. (You can also do the prior one in bzr of course.)

The other major difference with bzr is that revisions are hashed for integrity, but primarily identified by assigned ids. This avoids transitions when the representation changes and allows directly talking about revisions in foreign systems. But, hash or not, they still have globally unique ids.

Bazaar on the slow track

Posted Sep 13, 2012 19:42 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

> One approach is to literally throw that history away and just submit a plain patch, as is often done with git. I wanted to try something different that would keep all the history, but also have a view of which path through the dag was the main history.

note that git doesn't force you to throw away the history.

If you pull from the mainline, create your patch, and send a pull request, your history will show up in the main repository.

you can even edit your patch history prior to sending the pull request. This is commonly done by people doing major changes as it lets them clean things up and make each patch 'correct' and self contained rather than showing the reality where one patch may introduce a bug that's fixed several patches later.

the only question is defining "which path was the main history" because git really doesn't define a "main history".

Bazaar on the slow track

Posted Sep 19, 2012 14:22 UTC (Wed) by pboddie (guest, #50784) [Link] (2 responses)

note that git doesn't force you to throw away the history.

I think that the intention may have been to describe the apparently common practice, particularly amongst git-using projects, of aggressively rebasing everything and asking people to collapse their contributions into a single patch so that the project history is kept "clean".

Bazaar on the slow track

Posted Sep 19, 2012 15:31 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

one of the features of git is the ability to recreate and combine patches before pushing them upstream.

Yes, this can be abused to combine a huge amount of work into one monster patch.

But it can be used sanely to re-order and combine patches from a line of development into a clean series of logical patches.

When you are developing something, if you check it in frequently as you go along, you are going to have cases where you introduce a bug at one point and don't find and fix it for several commits. You are also going to have things that you do at some point that you find were not the best way to do something and that you change back later (but want to keep other work you have done in the meantime)

you now have the option of either pushing this history, including all your false starts, bugs, etc.

Or you can clean the history up, combining the bugfixes with the earlier patches that introduced the bug, eliminating the false starts, etc and push the result.

The first approach has the advantage that everything is visible, but it has the disadvantage that there are a lot of commits in the history where things just don't work.

If the project in question encourages the use of bisect to track down problems, having lots of commits where things just don't work makes it really hard for users trying to help the developers track down the bugs.

As a result, many projects encourage the developers to take the second approach.

Now, many developers misunderstand this to mean that they are encouraged to rebase their entire development effort into one monster patch relative to the latest head, but that's actually a bad thing to do.

And in any case, the history is still available to the developer, they are just choosing not to share that history with the outside world.

Bazaar on the slow track

Posted Sep 19, 2012 19:52 UTC (Wed) by smurf (subscriber, #17840) [Link]

What he said.

A "clean" history (meaning "to the best of my knowledge, every change transforms program X1 into a strictly better program X2") means that you can take advantage of one of git's main features when you do find a regression.

Bisecting.

If you do break something, "git bisect" requires ten compile-test-run cycles to find the culprit, among a thousand changes. Or twenty cycles if you have a million changes. (OK, more like 13 and 30, because history isn't linear, but you get the idea.) If you try to keep track of that manually you'd go bonkers.

Of course this isn't restricted to git. bzr and hg also implemented the command. The idea was too good not to. ;-)
I don't know how well they do in finding reasonable bisection points in a complex revision graph; git's algorithm is very good these days.

some hard (though not necessarily relevant) numbers

Posted Sep 11, 2012 21:50 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

As one can see from http://cia.vc/stats/vcs Bazaar doesn't get that much use in the (admittedly self-selecting) collection of projects followed by CIA bots.

Now, if there weren't any other similar software, that needn't matter. A lot more Word documents get created every day than git commits, but that's no reason for programmers to consider choosing Word over git. But the reality is that Bazaar isn't so different from other DVCSs, and while the difference between CIA's statistics for CVS or Subversion and say, Mercurial, might be accounted for by some small variation in usage style, the huge gap between Bazaar and almost any of the others can't be explained that way.

If there are ten (or as seems more likely from those stats, several hundred) times more git users than Bazaar users then on average Bazaar users must be a LOT more proactive in supporting Bazaar to have the same impact. That's just not likely to happen.

Bazaar on the slow track

Posted Sep 11, 2012 22:48 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

"If there were really a community of developers who would contribute if only the terms were more fair, an agreement-less Bazaar fork would almost certainly have emerged by now."

I am not sure about that. It doesn't seem like people are willing to fork over the issue of agreements unless there are other issues at play as well. Likely because there is no community of developers that even forms outside of the single dominant originator vendor in such cases. The forks that have emerged under similar circumstances have usually been formed by ex employees of that single vendor.

Bazaar on the slow track

Posted Sep 12, 2012 20:21 UTC (Wed) by ceplm (subscriber, #41334) [Link] (2 responses)

With every fork you have yet another choice ... do something else.

If MySQL users will finally get p*sed off enough to be willing to fork it, they won't do it (most likely). They will just go to MariaDB (or hopefully PostgreSQL, but that's another issue).

When bzr users will be missing some functionality in bzr, will they spent all that effort to create a fork of bzr which they will then have to maintain, or rather sit down and read http://git-scm.com/book ... it is really not that scary (anymore?).

Bazaar on the slow track

Posted Sep 13, 2012 9:55 UTC (Thu) by hingo (guest, #14792) [Link] (1 responses)

Eh... Are you aware that MariaDB *is* a MySQL fork! It was created by - you said it - pissed of MySQL developers.

Even better, there are 2 more active MySQL forks too, and historically there have been several.

Bazaar on the slow track

Posted Sep 13, 2012 11:52 UTC (Thu) by ceplm (subscriber, #41334) [Link]

Of course, I know that ... but for my point it is completely irrelevant.

Bazaar on the slow track

Posted Sep 11, 2012 22:55 UTC (Tue) by amk (subscriber, #19) [Link] (8 responses)

I think bzr lost mindshare early on due to unfortunate performance problems. The number of network operations wasn't optimized very carefully, so checking out and pushing took a long time on large repositories. Emacs wrestled with this a lot in converting from CVS to bzr; see http://osdir.com/ml/bazaar/2009-11/msg00912.html for an example. Later releases reduced the amount of network traffic, but I think bzr had already acquired a reputation as 'the DVCS that isn't fast', and so users are instead drawn to git or Mercurial.

Bazaar on the slow track

Posted Sep 12, 2012 2:08 UTC (Wed) by SEJeff (guest, #51588) [Link] (1 responses)

I'd argue that the problem wasn't speed (although that was important), but repository format. bzr changed on-disk format in non-compatible ways what, 3 times? I seriously forget. Sure git has added features in forwards compatible ways, but you won't see any issues with pushing to different versioned remote repos using git. You can with bzr.

That made it an absolute nonstarter for some things I was working on several years ago

Bazaar on the slow track

Posted Sep 12, 2012 8:12 UTC (Wed) by hrw (subscriber, #44826) [Link]

Speed was issue. At Linaro we imported gcc into bzr and then pointed Bazaar developers to it to show how slow it is. Lot of things got improved in last 2 years.

But personally I prefer git.

Bazaar on the slow track

Posted Sep 18, 2012 20:36 UTC (Tue) by fw (subscriber, #26023) [Link] (5 responses)

Just for testing, I pulled about 9.5 months of Emacs development using bzr 2.6.0dev2. It took 5.5 minutes and roughly 170 MB of network traffic. Cloning the entire Git mirror took 14 minutes and 690 MB. Now cloning from scratch is always more efficient, but these numbers still don't look very good for bzr.

Bazaar on the slow track

Posted Sep 19, 2012 11:03 UTC (Wed) by hummassa (guest, #307) [Link] (3 responses)

> I pulled about 9.5 months of Emacs development using bzr 2.6.0dev2. It took 5.5 minutes and roughly 170 MB of network traffic. Cloning the entire Git mirror took 14 minutes and 690 MB

Care to elaborate that? You just stated that git was 3x slower than bzr, so I'm confused.

Bazaar on the slow track

Posted Sep 19, 2012 11:17 UTC (Wed) by hummassa (guest, #307) [Link]

After re-reading, I *think* the "9.5 months" mean that the "entire git mirror" refers to more development time... (maybe twenty or so years?) can you clarify this? And as you stated, full mirroring is really fast...

Bazaar on the slow track

Posted Sep 21, 2012 19:37 UTC (Fri) by fw (subscriber, #26023) [Link] (1 responses)

Git had much more history to pull. I tried again with the last few days (both incremental this time), and the speed is comparable (15 seconds each). Git still transfers slightly less data (3.8 MB vs 4.3 MB). I should probably do this comparison again after two weeks.

Bazaar on the slow track

Posted Oct 3, 2012 10:07 UTC (Wed) by fw (subscriber, #26023) [Link]

I did another test, and the numbers are now:

bzr: 41s, 27.7 MiB
git: 35s, 24.9 MiB

So bzr and git are roughly in the same ballpark, at least for this test (pulling changes into a local repository which hasn't seen any local changes).

Bazaar on the slow track

Posted Sep 19, 2012 21:52 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. I just pulled the last five days of Emacs development with bzr 2.5. It pulled down 16905Kb at wildly varying rates all well below line speed, and re-evaluated its infuriating 'estimate' of amount to be transferred five times. Does anyone believe that Emacs actually had 17Mb of changes in the last week? You'd be right.

Getting a diff of the changes on trunk -- entirely in core -- took four seconds (not too shabby but still terribly slow compared to git, where in-core diffs often run at rates in excess of 30,000 lines per second), and revealed

311 files changed, 3025 insertions(+), 2658 deletions(-)

A wc of the output says

12952 55987 447812

so "bzr pull" had to receive roughly thirty times as much data as was actually changed, and that's despite the fact that patches contain lots of redundant context info that hasn't actually changed in any way at all.

I'm sorry, but no matter which way you slice it, bzr is still hilariously inefficient. It may not be *unusably* inefficient anymore, but that's damning with very faint praise.

Bazaar on the slow track -- history notes

Posted Sep 11, 2012 23:55 UTC (Tue) by martin.langhoff (subscriber, #61417) [Link] (21 responses)

Back when the BitKeeper debacle hit, Bazaar was Bazaar-NG, starting off as a fork of Tom Lord's TLA. At the time, I was struggling to maintain a series of private trees with a small team of programmers, and paying a lot of attention to what was happening in the VCS space.

When the git wave hit, it looked as if Bazaar took a while to figure out the internal data structures of git, and eventually learned a lot from them. They are not identical, of course, but the TLA data structures were a horridly bad fit for the job.

There was a long period of confusion -- circa 2006. All the while git's usability was, um, bad, but it's storage was rock-solid. Bazaar's storage was not considered very reliable, even by Martin Pool. This was the time when X.org, Mozilla and other high-profile / large repo projects were looking to migrate.

Once git's cli UI starting getting a bit more polished, around git 1.5, the "slightly better UI" justification for many of the other VCS started to dry up. VCSs are specialized tools, so when you invest in learning one (and you have to), a slightly steeper learning curve is very often worth it. So all git needed to do was to get close in usability to the others -- and it did. At that point, git's sheer flexibility and power closes the deal.

One VCS I do miss is darcs. Its internal data structures were flawed, but the UI was oh so elegant, specially for those of use suffering with TLA. Not sure if it was original, but I do think it set the UI standard for Mercurial and Bazaar (and git, once it got to the "make it usable" stage).

I am actually surprised that the Bazaar people haven't traded their core engine for git. If you want to support features git won't give you (explicit renames, for example :-) ) you can attach extra bits of metadata to trees and commit objects.

You can use that trick to prototype DVCS features ideas pretty quick, and you could implement a very good "usable-first" DVCS. There are many git "wrappers" that aim to preserve git purity (that is, they are compatible with standard git usage). That puts a lot of limitations on what you can do. If you break that taboo, git can be an outstanding storage engine for very fancy DCVS.

{ I am author of importers to git and git-cvsserver, as well as patches to git and the long-obsoleted cg. I helped several large profile projects evaluate git and import their repos (with mixed results). And I am always looking for time to try to fix some git usability pet peeves. }

Bazaar on the slow track -- history notes

Posted Sep 12, 2012 3:48 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

Speaking of git importers, I really miss good interop between git and other VCSen. For example git-remote-bzr is a bit buggy, needs a new maintainer in Debian and has some gaps in its mappings between git and bzr concepts. git-remote-hg still isn't merged into git upstream and git-remote-darcs doesn't exist.

Bazaar on the slow track -- history notes

Posted Sep 13, 2012 1:19 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link]

Please do report bugs in the git mailing list. IME, git has the best interop tools I've seen -- they only get better if you make noise about bugs you find in the mailing list...

Bazaar on the slow track -- history notes

Posted Sep 12, 2012 5:06 UTC (Wed) by abentley (guest, #22064) [Link] (3 responses)

Bazaar-NG was never a fork of Tom Lord's TLA. That fork was Baz, which was called "Bazaar" at the time. Bazaar-NG was always a from-scratch design intended to support lossless imports from Baz.

I don't think Martin considered Bazaar-NG's storage unreliable. Bazaar-NG was self-hosting in March after 3 months of development, and Martin wouldn't have done that if he didn't trust it. His original web site warned "This is pre-release unstable code. Keep backups of any important information.", but I think this was just an overabundance of caution.

One of the reasons Bazaar(-NG) didn't switch to git's core was because git didn't provide a library. And even if it had, it would have been in C, not Python. But we also wanted something that worked with our data model. We felt we could do at least as well as git in storing data, and I've never had reason to doubt the 2a format's efficiency.

Bazaar on the slow track -- history notes

Posted Sep 13, 2012 1:51 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link] (2 responses)

My memory was fuzzy in the baz/bazaarNG distinction. Thanks for clarifying.

On whether the reliability of storage and Martin Pool's regard of it... I have an anecdote :-)

I was sitting at Martin Pool's presentation in linux.conf.au 2006 (Dunedin, NZ). From the back of the room, in the QA part of the session, someone asked: "so, is it ready for real work? You see, I have this large codebase that's been developed for 25+ years. After several VCS migrations, it's in CVS with a messy repo due to migrations. We are a widely distributed team, and we are hurting. Should I be migrating to bzr now?"

Martin looked rather uncomfortable with the question, and muttered something like "not really, not yet". He had already been less than reassuring when I had asked whether Bazaar storage was delta-centric (darcs-like) or snapshot centric (git-like).

The "is it ready for real workdd?" question had come from Jim Gettys, who I did not know personally at the time. After the talk I asked him whether he had been talking about X.org and whether he could give me access to those messy X.org CVS repos. I would try importing them into git, and we could see if he liked the outcome.

It was the start of a long hard road -- it led to many improvements to git- cvsimport, yet the migration was done with parsecvs (written by Keith Packard).

I was at linux.conf.au to run a workshop on git; Linus joined us, so it stretched from 2 to 4hs. We had a much smaller room assigned than Bazaar, but you could feel we were rocking and rolling :-) I believe Matt Mackall was there too, talking about Mercurial, but I missed it.

This happened long ago -- and this is how I remember it. Quotes are as best as I can recall.

In my view, 2006/2007 was the time where the overall trends in the DVCS space got established; x.org migrated to git, Mozilla ran high profile bakeoffs between DVCSs, etc. And at that time Bazaar was on unfortunately on unsure footing (bad timing!). As a result, Git and Mercurial generally stole the show...

Bazaar on the slow track -- history notes

Posted Sep 13, 2012 7:34 UTC (Thu) by mbp (subscriber, #2737) [Link] (1 responses)

I think my discomfort would have been about performance for the size of the tree and history they were talking about, not about reliability. bzr was not ready for big trees in 2006 that time.

bzr has always had snapshot storage and never been darcs-like.

I reject, and resent, the implication that I publicly advocated something I privately didn't think was reliable.

Bazaar on the slow track -- history notes

Posted Sep 13, 2012 13:50 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link]

My apologies. I did not mean to cause offense. Time has its way of distorting memories, perhaps you or others have a different recollection?

My impression after your talk back then was that perhaps Bazaar-NG was performing or planning internal storage changes (or something like that) and that at that particular time those were awkward questions. Not that you did not trust or promote Bazaar, but that you were stating "not right now".

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 12, 2012 16:38 UTC (Wed) by walex (guest, #69836) [Link] (13 responses)

I like your discussion, and in particular the emphasis on storage structure as well as functionality. One of the big issues with SVN for example is the enormous number of small state files it creates in the working copy, and the rather inefficient repository storage too, once they deprecated the DB files.

I think that most recent Bazaar storage structures are not too bad, but that the Mercurial one is pretty terrible, the Git one is so-so, and by far the best is that used by Monotone, which is a single Sqlite file per repository. That makes tree searches, backups, and in general all whole-repository and filetree oriented operations a lot faster and easier.

Also Git and Monotone are implemented fairly well in compiled languages, and can be much faster than Python-implemented Bazaar and Mercurial, even if a bit more careful for the latter two has improved the situation.

Interestingly Monotone, which inspired a lot the design of Git, is also functionally rather complete, and works well, and I think that it is for most projects the most appropriate VCS, followed by Git itself, then Bazaar and not far behind Mercurial.

It is a pity that TLA and DARCS are more often mentioned than Monotone, which has a pretty deliberate, careful design and implementation, even if it is one of the Gang Of Four major modern DVCSes.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 12, 2012 17:20 UTC (Wed) by BlueLightning (subscriber, #38978) [Link]

I can't speak to the current state of Monotone - it's not unlikely it has improved, but at the time when the OpenEmbedded project used it (some years ago now) it was agonisingly slow with large codebases. In fact was so bad that instead of doing the initial fetch of the repository we got people to download a snapshot and then update from that.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 12, 2012 23:15 UTC (Wed) by akupries (guest, #4268) [Link]

storage structures [...] by far the best is that used by Monotone, which is a single Sqlite file per repository.

Richard Hipp, sqlite's author wrote an SCM using a single sqlite file per repository as well. It is called Fossil. It manages the sqlite repository now.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 13, 2012 1:58 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link] (10 responses)

AIUI, Monotone using SQLite is unfortunately a disaster in terms of performance. Linus tried it early, before starting git; liked some of the design decisions, abhorred others (signing everything, SQLite).

Monotone using SQLite is a boon for programmers. SQL is easier to wrestle than complex on-disk and in-memory data structures, specially if you are changing the layout. But git design learned from many sources (including Monotone) and had a pretty set data structure from the beginning.

With that clearly-defined data structure, Linus and other kernel hackers cranked out very efficient code. IIRC, Monotone used to take hours to import _one_ snapshot of a kernel, where git could do it in <10s.

See the very very early emails in the git list, by Linus, on his design research and early tests with monotone.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 13, 2012 7:54 UTC (Thu) by graydon (guest, #5009) [Link] (9 responses)

No, monotone was never that slow. It handled kernel trees (at least at the time I was working on it; those and gcc trees were the benchmark testcases). Linus likes to exaggerate this matter, along with chastising us for our terrible "object oriented C++" code and various other hyperbole. I assume he didn't actually read it.

That said, monotone was unusably slow _when compared to git_, and as project histories and development parallelism has grown, that delta has become an easy and correct criterion for picking git for production in most cases. Git also picked a more sensible branch-naming model (local, per-repo, no PKI; less ambitious but easier and more powerful), embraced history-rewriting early and aggressively, had the benefit of hindsight in most algorithms, declined to bother tracking object identity (turns out to cost more performance than it's worth), figured out submodules, etc. etc. Git won this space hands down. There's no point competing with it anymore, imo.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 15, 2012 20:54 UTC (Sat) by cmccabe (guest, #60281) [Link]

I always get a chuckle when people try to compare the speed of most DVCSes to git. It's like hearing someone say his bicycle can out-perform your ferrari-- if there's a good tail-wind, and the road is downhill, and maybe if Lance Armstrong is the rider... Kudos to you for being realistic about the issue. And monotone was cool, back in the day.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 17, 2012 15:16 UTC (Mon) by zooko (guest, #2589) [Link] (7 responses)

If I recall correctly on the day (weekend?) that Linus tried monotone, the then-current release of monotone had some diagnostic/debugging/profiling code compiled in which caused it to have superlinear runtime for some computation or other. Correct me if I'm wrong, Graydon, as I think what I'm recalling is from something you wrote shortly thereafter.

It's one of those "for want of a nail the horseshoe was lost" kinds of moments in history -- if monotone had been fast enough for Linus to use at that time then presumably he never would have invented git.

And while *most* of the good stuff that the world has learned from git is stuff that git learned from monotone, I do feel a bit of relief that we have git's current branch naming scheme. Git's approach is basically to not try to solve it, and make it Someone Else's Problem. That sucks, it leads to ad-hoc reliance on DNS/PKI, and it probably contributes to centralization e.g. github, but at least there is an obvious spot where something better could be plugged in to replace it. If we had monotone's deeper integration into DNS/PKI (http://www.monotone.ca/docs/Branches.html), it might be harder for people to understand what the problem is and how to change it.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 15:25 UTC (Tue) by graydon (guest, #5009) [Link] (6 responses)

I don't think it was just a matter of a missing nail in a horseshoe. If I _had_ to point to a single matter, it would center on identity-tracking (that is, not "just dumb content tracking"). We initially just did content-tracking alone -- which was orders of magnitude faster -- and found that we were stapling together too many ad-hoc merge "algorithms" to reconstruct events like file and directory renames, and java users were complaining about the inaccuracy of those, so we wound up building a large (and as it turns out, computationally expensive) secondary layer of logic concerned with file and directory object lifecycles. That's probably the source of the lion's share of the costs; but even if we hadn't done that, I'm sure the amount of in-memory transformations and verification, data re-parsing, crypto, and simple buffer-copying / sqlite-IO would probably have doomed us going up against kernel engineers. They think in a much closer to "zero copies and never calculate anything twice" mode. Very hard to compete with, given my background and coding style. I'm happy to yield defeat on implementation here; git _flies_. Very impressive implementation (though I do wish it'd integrate rolling-checksum fragment-consolidation in its packfiles, a la bup).

All that's a distraction though, at this stage. Git won; but there's more to do. I agree with you that the residual/next/larger issue is PKI and naming. Or rather, getting _rid_ of PKI-as-we-have-tried-it and deploying something pragmatic, decentralized and scalable in its place for managing names-and-trust. The current system of expressing trust through x.509 PKI is a joke in poor taste, and git (rightly) rejects most of that in favour of the three weaker more-functional models: the "DNS and soon-to-be-PKI DNSSEC+DANE" model of global-name disambiguation, the "manual ssh key-exchange with sticky-key-fingerprints" model of endpoint transport security, and the (imo strictly _worse_) "GPG web of trust" model for long-lived audit-trails. The three of these systems serve as modest backstops to one another but I still feel there's productive work to do exploring the socio-technical nexus of trust-and-naming as a more integrated, simplified, decentralized and less random, more holistic level (RFCs 2693 and 4255 aside). There are still too many orthogonal failure modes, discontinuities and security skeuomorphisms; the experience of naming things, and trusting the names you exchange, at a global scale, still retains far too much of the sensation of pulling teeth. We wind up on IRC with old friends pasting SHA-256 fingerprints of things back and forth and saying "this one? no? maybe this one?" far too often.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 18:59 UTC (Tue) by jackb (guest, #41909) [Link] (5 responses)

All that's a distraction though, at this stage. Git won; but there's more to do. I agree with you that the residual/next/larger issue is PKI and naming. Or rather, getting _rid_ of PKI-as-we-have-tried-it and deploying something pragmatic, decentralized and scalable in its place for managing names-and-trust. The current system of expressing trust through x.509 PKI is a joke in poor taste, and git (rightly) rejects most of that in favour of the three weaker more-functional models: the "DNS and soon-to-be-PKI DNSSEC+DANE" model of global-name disambiguation, the "manual ssh key-exchange with sticky-key-fingerprints" model of endpoint transport security, and the (imo strictly _worse_) "GPG web of trust" model for long-lived audit-trails. The three of these systems serve as modest backstops to one another but I still feel there's productive work to do exploring the socio-technical nexus of trust-and-naming as a more integrated, simplified, decentralized and less random, more holistic level (RFCs 2693 and 4255 aside). There are still too many orthogonal failure modes, discontinuities and security skeuomorphisms; the experience of naming things, and trusting the names you exchange, at a global scale, still retains far too much of the sensation of pulling teeth. We wind up on IRC with old friends pasting SHA-256 fingerprints of things back and forth and saying "this one? no? maybe this one?" far too often.

My theory is that PKI doesn't work because it is based on a flawed understanding of what identity actually means.

The fraction of the population that really understands what it means to assign cryptographic trust to a key is statistically indistinguishable from "no one". Maybe the reason that the web of trust we've been promised since the 90s hasn't appeared yet is because the model itself is broken.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 19:43 UTC (Tue) by hummassa (guest, #307) [Link] (1 responses)

> The fraction of the population that really understands what it means to assign cryptographic trust to a key is statistically indistinguishable from "no one". Maybe the reason that the web of trust we've been promised since the 90s hasn't appeared yet is because the model itself is broken.

Ok, but... what is the alternative?

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 20:05 UTC (Tue) by jackb (guest, #41909) [Link]

Now that people are carrying mobile, internet-connected computers around with them basically all the time key signing can be automated.

The question of "does the person standing in front of me control a particular private key" can be answered by having each person's smartphone sign a challenge and exchange keys via QR codes (bluetooth, NFC, etc). This step should require very little human interaction.

That question, however, does not establish an identity as we humans understand it. Identity between social creatures is a set of shared experiences. The way that you "know" your friends is because of your memories of interacting with them.

Key signing should be done in person and mostly handled by an automated process. Identity formation is done by having the users verify facts about other people based on their shared experiences.

If properly implemented the end result would look a lot like a social network that just happens to produce a cryptographic web of trust as a side effect.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 20:23 UTC (Tue) by graydon (guest, #5009) [Link]

I agree. My hunch (currently exploring in code) is that a more useful model involves defining trust in reference to cross-validation between multiple private small-group communication-histories. Put another way: identity should adhere to evidence concerning communication-capability (and the active verification thereof), not evidence of decrypting long-lived keys. Keys should always be ephemeral. They'll be broken, lost or stolen anyways; best to treat them as such.

(Keep in mind how much online-verification comes out in the details of evaluating trust in our key-oriented PKI system anyways. And how often "denying a centralized / findable verification service" features in attack scenarios. Surprise surprise.)

So, I also expect this will require -- or at least greatly benefit from -- a degree of "going around" current network infrastructure. Or at least a willingness to run verification traffic over a comfortable mixture of channels, to resist whole-network-controlling MITMs (as the current incarnation of the internet seems to have become).

But lucky for our future, communication bandwidth grows faster than everything else, and most new devices have plenty of unusual radios.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 20:25 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

PKI is a failure on all levels, starting from technical and going up to the social/management level.

For example, is there anybody here who can claim enough of ASN.1 knowledge to parse encoded certificates and keys? I certainly don't, every time I need to generate a CSR or a key, I go to Google and search for the required command-line to make OpenSSL spit out the magic binhex block.

Then there's a problem with lack of delegation. It's not possible to create a master cert for "mydomain.com" which I then can use to sign "host1.mydomain.com" and "host2.mydomain.com".

And so on. I'd gladly help a project to replace all this morass with clean JSON-based certificates with clear human-readable encoding.

Bazaar on the slow track -- Montone gets too little attention

Posted Sep 18, 2012 21:16 UTC (Tue) by jackb (guest, #41909) [Link]

I think there are two components necessary to build a web of trust that real people will actually use. First is automated in-person key signing that I described in an eariler post. The second part is an online database of facts about a particular identity.

The database would consist of one table that associates arbitrary text strings with public key IDs, and another table containing cryptographically-signed affirmations or refutations of the entries in the first table.

An example of an arbitrary text string could be a legal name, an email address, "inventor of the Linxu kernel", "CEO of Acme, Inc.", etc.

Everybody is free to claim anything they want, and everyone else is free to confirm or refute it. A suitable algorithm would be used to sort out these statements based on the user's location in the web of trust to estimate the veracity of any particular statement.

The value of the web of trust depends on getting people to actually use it so the tools for managing it would need to be enjoyable to work with instead of painful. That's one reason I think making the user interface similar to a social network because the emperical evidence suggests that people like using Facebook more than they like using GPG or OpenSSL. The other reason is that social networks better model how people actually interact in real life so making the web of trust operate that way is more intuitive.

Bazaar on the slow track -- history notes

Posted Sep 17, 2012 11:52 UTC (Mon) by douglasbagnall (subscriber, #62736) [Link]

> I am actually surprised that the Bazaar people haven't traded their core engine for git.

The other day I heard a Canonical employee advocating bzr as a git front-end. The argument was that nobody suffers if you use Bazaar locally and Git remotely, so bzr people should just do that and stop fussing. As you suggest, they may have been glossing over incompatibilities in the models, or perhaps they haven't hit them in practice.

Bazaar on the slow track

Posted Sep 12, 2012 8:11 UTC (Wed) by afayolle (guest, #45179) [Link] (1 responses)

A non-obvious drawback of bzr when compared to git or hg is... the command name itself, when typed on most keyboards. In that area, hg only looses it to a yet to be invented VCS tool that would be called jf :-) and bzr is terrible when you get to type that command over and over again.

I'm forced to use bzr because the projects I work on are collectively hosted on launchpad, and I have 'alias b=bzr' in my .bashrc to alleviate this.

Bazaar on the slow track

Posted Sep 12, 2012 18:06 UTC (Wed) by apoelstra (subscriber, #75205) [Link]

>A non-obvious drawback of bzr when compared to git or hg is... the command name itself, when typed on most keyboards.

I never noticed this until your comment, but it is interesting to note that typing 'bzr' on dvorak is almost exactly the same movement as on qwerty -- except you use your right hand instead of your left!

(The specific keys, to a qwerty user, are 'n/o'.)

Bazaar on the slow track

Posted Sep 12, 2012 11:46 UTC (Wed) by danpb (subscriber, #4831) [Link] (12 responses)

> perhaps Bazaar has simply lost out to competing projects which have
> managed to advance further and faster. For sheer functionality, Git is
> hard to compete with. For those who are put off by the complexity of Git,
> Mercurial offers a gentler alternative without compromising on features.
> Perhaps most potential users just do not see anything in Bazaar that is
> sufficiently shiny to attract them away from the other tools.

I think this is really the crux of the matter. There was a window of a few years when a whole range of new dVCS systems were competing to replace the traditional choice of CVS (or SVN), as the defacto standard for Open Source projects. I initially rather liked Mercurial for its user friendliness and used it for a number of projects. It got to the point where even though I preferred Mercurial, so many other projects I needed to interact with were using Git that I had no choice but to learn Git.

In other words, Git has reached that critical mass where everyone in the open source world needs to learn how to use it eventually. Once you've learnt GIT, its breadth of features means there is no compelling reason to carry on using things like Mercurial, Bazaar, Subversion, or any of the others.

I see projects like OpenStack, hosted on Launchpad, casting off Bazaar and switching to using GIT (hosted on GITHub). Similarly projects hosted by Apache, using GIT for their primary dev work, even though they all "officially" using the Subversion for their master tree. Interestingly I'm finding that a very large proportion of people I interview for job positions now have GIT experience from company internal work, even if they haven't worked on Open Source projects before.

Bazaar or the other dVCS tools aren't going away, but I don't see them catching up with GIT at this point. The Debian package stats reinforce this belief

http://qa.debian.org/popcon-graph.php?packages=subversion...

Bazaar on the slow track

Posted Sep 12, 2012 12:06 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

git was named git-core earlier on, imo that makes it even clearer:

http://qa.debian.org/popcon-graph.php?packages=subversion...

git was the gnu interactive tools package, named gnuit these days.

Bazaar on the slow track

Posted Sep 12, 2012 15:03 UTC (Wed) by robert_s (subscriber, #42402) [Link] (10 responses)

"Once you've learnt GIT, its breadth of features means there is no compelling reason to carry on using things like Mercurial"

I too am am Mercurial user who's been "forced" to learn git, but The compelling reason that causes me to still manage _my_ projects in mercurial is the fact that it's _much_ harder to shoot yourself in the foot in mercurial.

Even once you've got past git's steep and puzzling learning curve, working with branches in git feels a bit like doing a difficult juggling act with HEADs, and if you accidentally drop one of them (or even just accidentally specify the targets the wrong way round in a git rebase) you can spend an entire afternoon looking for the remains in git fsck.

And then of course there are the nice things like commit phases that mercurial have been adding lately.

Bazaar on the slow track

Posted Sep 12, 2012 15:54 UTC (Wed) by mgedmin (guest, #34497) [Link] (1 responses)

It's easier to recover from a bad rebase with git reflog than with git fsck.

Bazaar on the slow track

Posted Sep 13, 2012 0:06 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite. I'd venture to say that if you're using git fsck, you haven't had a hardware failure, and you're not hacking git, you're probably doing something unnecessary. It's *that* reliable. (I'd actually almost forgotten that git fsck existed: I haven't run it in anger in years.)

I concur that it is nearly impossible to lose work in git: making a new branch before doing something you're scared about suffices in basically all cases, and if you forget that there is the reflog. I've done massive history rewrites and routinely do partial history rewrites and tree partitions and have never lost a byte. (Having said that, I'm sure something horrible will happen now and I'll lose the last year's work or something. Not even git is immune to Murphy's Law.)

Bazaar on the slow track

Posted Sep 12, 2012 19:20 UTC (Wed) by price (guest, #59790) [Link] (3 responses)

> if you accidentally drop one of them [...] you can spend
> an entire afternoon looking for the remains in git fsck.

You want to use the reflog. Take two minutes and read about it right now:
http://gitfu.wordpress.com/2008/04/06/git-reflog-no-commi...
http://www.kernel.org/pub/software/scm/git/docs/git-reflo...

You will be much, much happier as a result the next time you drop something. Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.

(The main exception is if you only realize you wanted it weeks after discarding it. By default Git does eventually garbage-collect commits that no refs point to.)

Bazaar on the slow track

Posted Sep 12, 2012 21:03 UTC (Wed) by robert_s (subscriber, #42402) [Link]

Thanks for this - will probably save me a lot of time.

Bazaar on the slow track

Posted Sep 12, 2012 23:43 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

> Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.

AFAIK, the reflog is deleted when the branch is deleted. So if it happened on a branch you later deleted, you just lost the reference and it is git fsck time.

I would prefer if it left the reflogs for deleted branches around, and garbage-collected them later.

Bazaar on the slow track

Posted Sep 12, 2012 23:55 UTC (Wed) by price (guest, #59790) [Link]

Even when you delete a branch, the old commits will all still be in the reflog for HEAD (unless they're past the expiration time anyway -- or you delete HEAD itself, which is beyond the ken of normal Git commands.) So they'll still show up in 'git reflog show' (which refers to HEAD by default), and you can still recover them just fine.

I do agree that it would be better if Git kept the reflogs around. A case where this does matter is if you want to keep an archival record of changes to the repository, e.g. in a organization's central repository that everybody pushes to. It's simple to configure Git never to expire old reflog entries (see gc.reflogexpire and gc.reflogexpireunreachable in git-config(1)), but AFAIK there's no way to configure it to keep reflogs of deleted refs.

Bazaar on the slow track

Posted Sep 16, 2012 12:44 UTC (Sun) by kleptog (subscriber, #1183) [Link] (1 responses)

I'm a git user "forced" to learn Mercurial. While I agree that Mercurial has many of the same features as git, I feel git works much better for my workflow. The index, "git add/remove -p" and "git rebase -i" are my very close friends.

The first thing I noticed is Mercurial's rigid adherence to "committed is unchangeable". For me a commit is more a checkpoint, but it's not necessarily something finished. Usually I develop something as a series of patches, commit various bug fixes and use rebase to fold the bugfixes into the appropriate patch.

I was relieved to find the MQ extension which gives you much the functionality but with a very obtuse UI. The phases you point to seem to be a further step in the right direction. Though I feel their painting themselves into a corner since now a review tool like Gerrit becomes impossible: you push to the review tool which would make your patch immutable, while the whole point of the review is to be able to fix the patch!

Other rough edges: that the "pager" extension is not standard, there is no justification for "hg log" on the terminal filling your scrollback buffer with the entire history of your project. The "color" extension could also be better advertised.

My feeling is that git is a tool for people who deal with large numbers of branches and patches daily, and Mercurial is for people push a few patches around occasionally.

Bazaar on the slow track

Posted Sep 16, 2012 13:04 UTC (Sun) by dlang (guest, #313) [Link]

I ran across this post some time back, it seems to fit what I know on the subject quite well

http://xentac.net/2012/01/19/the-real-difference-between-...

Bazaar on the slow track

Posted Sep 17, 2012 18:31 UTC (Mon) by luto (subscriber, #39314) [Link]

I used to agree, except that I've shot myself in the foot numerous times using Mercurial in ways that would be impossible in git. Git never throws away commits until you ask it to. Mercurial throws them away in the process of rebasing, and it even requires you to strip things before you rebase their ancestors. This means that, if the rebase screws up [1] [2], then you lose data.

[1] Mercurial also seems to screw up more often. When it finishes embracing the three-way merge, it'll work better. The Mercurial tools certainly are prettier, though.

[2] Mercurial is worse at doing bizarre merges than git. At some point I'll dig up the example that broke Mercurial and file a bug. At least this failure mode doesn't eat my data. (Basically, the git "recursive" algorithm, while imperfect, is better than Mercurial's approach of choosing an arbitrary base from the set of bases with no possibility of overriding the choice.)

Bazaar on the slow track

Posted Sep 26, 2012 9:34 UTC (Wed) by makomk (guest, #51493) [Link]

git rebase should always save the previous state of the branch being rebased in ORIG_HEAD, so if you screw it up and get the branch names the wrong way around you should just be able to do "git reset --hard ORIG_HEAD" so long as you realise immediately (or "git rebase --abort" if the rebase failed partway through).

Bazaar on the slow track

Posted Sep 12, 2012 12:59 UTC (Wed) by cmorgan (guest, #71980) [Link] (6 responses)

>>The Bazaar (or "bzr") version control system lacks the visibility of systems like Git or even Mercurial.

Sometimes projects just run out of steam because something else has caught wind. Having worked on projects that have had their moment and then their sunset it does take some time to adjust and move on.

With the rise of Git and related things like GitHub maybe it makes sense for Canonical to cut their losses and migrate to what appears to be a solution that more developers are happy with. They could always try to see if their "must have" features (whatever it is that keeps them using Bazaar other than familiarity and the cost to migrate away from it) could be things that could be integrated into Git.

Bazaar on the slow track

Posted Sep 13, 2012 10:11 UTC (Thu) by hingo (guest, #14792) [Link] (5 responses)

Yes!!! My wish in this area is a command line interface to git that would use bzr semantics, but store commits as git (and github) behind the scenes.

The cli is really the strength of bzr. You typically can get your workflow done with 3 commands: bzr branch, bzr commit, bzr push. Ok, so you need init and pull and merge too, but that's it. Even though checkout type of workflow is supported, you shouldn't really use it.

What I really like is the fact that all branches are laid out in their own directories. This is yet another incarnation of the unixy "everything is a file" approach. I can reuse my knowledge of basic unix commands that I don't need to learn a specific bzr command for: Change to working in another branch: that's "cd". See what branches are available: "ls". Delete a branch: "rm". Also there's no separate clone vs branch, everything is just a branch.

If someone implemented a git client with these semantics and workflows, it would be an immediate reason to stop using bzr for me at least. This should be perfectly doable while staying 100% with the internal repo format of git.

Bazaar on the slow track

Posted Sep 13, 2012 11:21 UTC (Thu) by juliank (guest, #45896) [Link] (3 responses)

Part of your text works for git as well:

> The cli is really the strength of git. You typically can get
> your workflow done with 3 commands: git clone, git commit,
> git push. Ok, so you need init and pull and merge too, but that's it.

But I still wonder why you never need to look at status or diff.

Bazaar on the slow track

Posted Sep 13, 2012 12:34 UTC (Thu) by hingo (guest, #14792) [Link] (2 responses)

This has not been my experience with git. As I remember from last time, I have to separately clone the git repo and then create my own branch or checkout an existing one. When I work with multiple branches I need to continuously checkout to jump to the one I want laid out in the filesystem. With bzr, all of this is just one command: branch. (Then you use cd to switch.)

Ok, maybe sometime I have actually used diff and status :-) But if you never make mistakes then you don't need to ;-)

Bazaar on the slow track

Posted Sep 13, 2012 12:43 UTC (Thu) by juliank (guest, #45896) [Link] (1 responses)

Normally, git automatically checks out whatever HEAD points to. You can also specify another branch to checkout when cloning, using the -b parameter:

git clone -b branch-i-want-to-look-at git://example.com/example.git

Bazaar on the slow track

Posted Sep 13, 2012 12:48 UTC (Thu) by hingo (guest, #14792) [Link]

Ok, so you can combine that into a single command, but in terms of cognitive overhead you are still doing 2 things. In bzr the branch is the only thing you need to know, and HEAD/trunk is no different from any other branch.

It's like the difference between Mac and Windows, if you will. One has 1 mouse buttons, the other has 2, and the first one is considered more elegant because of that :-)

Bazaar on the slow track

Posted Sep 13, 2012 15:52 UTC (Thu) by cdmiller (guest, #2813) [Link]

Gotta second the workflow simplicity. Add, branch, commit, merge, status, and occasionally resolve, diff, push are all that has been needed for shared sysadmin stuff like puppet configs. Our database folks use bzr for their stuff, usually small independent reporting tools. Also second the branch per directory layout, and everything being just a branch. KISS.

Bazaar on the slow track

Posted Sep 12, 2012 13:24 UTC (Wed) by philipstorry (subscriber, #45926) [Link] (2 responses)

Off on a tangent here... I wonder how many non-development users Bazaar has?

I'm a systems administrator, and when setting up some Ubuntu Server boxes I chose to version control the /etc path using etckeeper. Funnily enough, Bazaar was Ubuntu's default choice for the VCS that etckeeper used. (etckeeper is apparently agnostic about such things.)

From using Bazaar there, it's kind of snowballed. The one bit of development I do (which isn't much) now uses Bazaar, but only behind the scenes - not as a DVCS. I just picked it because I was familiar with it.

I also use it to version control my writing (mostly short stories, some novels). That can be fairly handy when you get frustrated and delete an entire passage out of frustration, only to find two days later that the problem was elsewhere!

It's quick, simple, and with Bazaar Explorer it's pretty simple even for a novice to use. It may not be the developer's first choice, but should version control really only be used by developers?

Apple have added versioning into their file handling APIs. If Canonical did the same, then I suspect they'd pick Bazaar. At this point I'm just thinking off the top of my head, mind you. But then, none of the other DVCSes are sponsored by a company that's trying to improve the computing experience.

Bazaar on the slow track

Posted Sep 13, 2012 16:26 UTC (Thu) by joey (guest, #328) [Link] (1 responses)

It's possible that your distribution has chosen to modify etckeeper so
its default VCS is not git -- if they have please complain to them,
as they're making things unnecessarily difficult for you, and causing
unnecessary divergence of etckeeper installations.
You should only be using etckeeper with a VCS other than git if you're
in love with the other VCS.

-- From its README.

Bazaar on the slow track

Posted Sep 14, 2012 12:20 UTC (Fri) by philipstorry (subscriber, #45926) [Link]

Cor. I never knew that.

I'd thought it was somewhat agnostic about which VCS it used. I doubt I'll switch now - a quick google shows it is possible to convert, but it's more hassle than I can be bothered with.

It's working fine with bzr, and it's Friday. So to change it breaks the two golden rules:
* It Ain't Broken, So Don't Fix It
* Don't Fiddle[1] With It On Friday

Thanks for pointing that out though - it's good to know I may need to do it in the future, if bzr support ever wanes for the etckeeper project...

--------
[1] Alternative verbs have seen use at this position.

Ah yes

Posted Sep 12, 2012 14:01 UTC (Wed) by corbet (editor, #1) [Link] (3 responses)

Pretty amusing to think that I forgot totally about this moment in history while writing the article:

A few years ago the core Mercurial and Bzr developers met in London for a weekend to compare notes and came to a tentative agreement that merging the two projects would be a good idea. This idea was very quickly torpedoed by Mark Shuttleworth's insistence that whatever project resulted would have to have copyright held by Canonical. The stated reason was allowing proprietary feature extensions as part of their Launchpad strategy.
I wrote Mercurial to be Free with a capital 'F' as a reaction to the object lesson of Bitkeeper. So entrusting my work to an organization that had plans to embrace and extend it was just not going to happen.

— Matt Mackall

Ah yes

Posted Sep 12, 2012 14:55 UTC (Wed) by pboddie (guest, #50784) [Link] (2 responses)

Ben Finney comes closest to the most probable explanation for the lack of developer interest, I think. Canonical chose to do everything in their own walled garden (Launchpad) with their own technologies (Bazaar-NG) and expected people to play along.

It's one thing to have various technology decisions influencing any project that Canonical is involved in, even though this will deter outsiders by itself; it's another to see Canonical wanting to exercise control over the products of such development as well.

You can certainly lean on the community to do the hard work if they benefit as much from it as you do, but as soon as you ask them to benefit less (and here I ignore the excuses about Canonical's unique stewardship role and corresponding privilege - on whom does the hard work of quality assurance and other tedious stewardship matters fall, exactly, if not the community in many cases?) then they will exercise their rights as volunteers and indulge some other projects instead.

Ah yes

Posted Sep 17, 2012 20:18 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (1 responses)

There's a critical point here I think needs to be stressed.

Bzr is primarily used as a tool to interact with launchpad.net. It's never really garnered significant adoption as a standalone tool. Yes some people do use it outside of launchpad, I'm not saying there is zero interest in bzr sans launchpad integration, just that i don't see critical mass in bzr community if launchpad integration were lost.

Because of the intimately tied nature with a Canonical controlled service (launchpad) there is less overall incentive for an external to try to create and lead a competing fork for fear of creating an incompatibility with the launchpad.net service requirements. It's forkable, the license on the code assures that is a possible future, but I doubt anyone is going to ever seriously do it.

It's a deep tangle.

I've yet to hear of someone attempting to take the launchpad.net sources and spinning in an alternative site. If someone did that, forked the launchpad.net codebase and spun up a implementation outside of Canonical's control, then a fork of bzr would be an obvious part of that much more involved effort. In for a penny in for a pound.

The irony of course being that the deep integration with launchpad is probably the only reason keeping bzr alive as a project at all at this point. If Canonical threw away launchpad entirely and started from scratch today... I'd wager they'd pick up git as part of the scaffolding. bzr is just a long lived piece of technical debt at this point for the launchpad team inside Canonical.

-jef

LP-bzr vs. LP-git?

Posted Sep 17, 2012 23:25 UTC (Mon) by smurf (subscriber, #17840) [Link]

Actually, I'd assume that replacing bzr with git in Launchpad would be reasonably straightforward.

Bazaar on the slow track

Posted Sep 12, 2012 14:54 UTC (Wed) by zooko (guest, #2589) [Link] (1 responses)

I like Corbet's inclusion of other perspectives than the "horse race" perspective. It can be fun and exciting to imagine open source projects as horses at a race, or as combatants in an arena, but when I'm not thinking in those terms, I realize that bzr is working well for me.

I use bzr to interact with projects that use it. It was easy enough to install and to learn the basic (getting a copy, updating to the latest version, submitting an occasional patch). It's efficient enough. It has not yet stunned me with an incomprehensible and intimidating error message. I'm basically satisfied with it.

Likewise I'm pretty satisfied with mercurial, which I also use only for occasional interaction with projects that use it.

Now git and darcs, I've used -- or tried to use -- extensively in many of my own projects and for my employers, and with both git and darcs I have a love/hate relationship. It's complicated.

Then there are the projects that still use svn or cvs. I find it mildly annoying to try to interact with those projects using those old tools.

Bazaar on the slow track

Posted Sep 12, 2012 21:03 UTC (Wed) by marcH (subscriber, #57642) [Link]

If you know a bit about git already then git-svn is definitely the best SVN client ever.

Bazaar on the slow track

Posted Sep 12, 2012 15:39 UTC (Wed) by shieldsd (guest, #20198) [Link] (32 responses)

Canonical should get with the program by using git.

Git has achieved the status of Linux itself. Just as Linux is now, and will remain, the dominant Unix kernel,git will be the dominant distributed version control system for the foreseeable future.

Though Mercurial has a following, I can't see how it can keep up with git.

Canonical's branching off on its own will just move it farther and farther from the mainstream. It's hard to see what they gain by going this route.

thanks,
dave shields

Bazaar on the slow track

Posted Sep 12, 2012 16:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Mercurial is not bad. It's basically "git for people who don't like git" and is more-or-less feature complete. It also has a fairly large following, so it's unlikely to die.

Bazaar on the slow track

Posted Sep 12, 2012 18:25 UTC (Wed) by smurf (subscriber, #17840) [Link] (30 responses)

Canonical is very unlikely to do so though. They're off doing their own thing, not only with bzr vs. git, but also with upstart vs. systemd, and some other parts of critical Linux and Gnome and … infrastructure.

IMHO this is not a sustainable long-term strategy.

Bazaar on the slow track

Posted Sep 12, 2012 18:27 UTC (Wed) by dlang (guest, #313) [Link] (28 responses)

upstart predated systemd, so claiming that they are going off on their own with that is misleading at best.

as much as the systemd people don't want to let it be known, not everyone has accepted it.

Bazaar on the slow track

Posted Sep 12, 2012 20:41 UTC (Wed) by cmccabe (guest, #60281) [Link] (27 responses)

It is true that Upstart came before systemd. However, no other major distro is using upstart any more besides Ubuntu. wikipedia informs me that Maemo used it, and so did WebOS, but that's mostly a historical note at this point.

So yes, I would say that Canonical is very much going off on their own with this project. The fact that they require copyright assignment probably hasn't helped matters.

In general I feel like Canonical has been creating a lot of questionable forks: bzr versus git, upstart versus systemd, Unity versus GNOME. They've always claimed to be UI experts, but they don't seem to be focusing their effort where it counts.

Bazaar on the slow track

Posted Sep 12, 2012 20:55 UTC (Wed) by dlang (guest, #313) [Link] (24 responses)

I believe that Debian (and therefor almost all of the family of debian derived distros, of which Ubuntu is the biggest) is also using upstart.

really it's only the Fedora based distros that have switched, along with a few others, but for every other one that has switched, a non-debian derived distro can be pointed to that hasn't switched.

RHEL may or may not switch in the future. The systemd people will say that it will switch, but we'll see how the datacenter admins that RHEL is built for respond (they don't need many of the desktop based features of systemd and are are both more comfortable and more likely to have odd init stuff that will be affected.

As for Unity vs GNOME, as GNOME3 was released, the distros have splintered like a glass thrown onto concrete. Yes Unity is one of the fragments, but it's far from the only one.

Bazaar on the slow track

Posted Sep 12, 2012 21:11 UTC (Wed) by marcH (subscriber, #57642) [Link]

> RHEL may or may not switch in the future. The systemd people will say that it will switch, but we'll see how the datacenter admins that RHEL is built for respond (they don't need many of the desktop based features of systemd and are are both more comfortable and more likely to have odd init stuff that will be affected.

Plus: they don't care about systemd optimizations and dynamic features. And they'd rather hack and trace shell scripts than use gdb and cc.

Bazaar on the slow track

Posted Sep 12, 2012 21:13 UTC (Wed) by Teho (guest, #86286) [Link]

Debian doesn't use Upstart and RHEL 7 will be using systemd (it was confirmed in Red Hat summit 2012) and it's going to be released in 2013. Mageia and Mandriva have also already switched to systemd and Arch Linux and Chakra will be doing so shortly. systemd is very modular and designed to work well in embedded systems and servers and not just desktops. To my understanding it was first adopted by embedded systems and it's now part of GENEVI core platfrom so it's supported by numerous different distributions including Ubuntu IVI. It's also part of both Mer and Tizen mobile Linux operating systems.

Bazaar on the slow track

Posted Sep 12, 2012 21:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

"really it's only the Fedora based distros that have switched, along with a few others"

You are clearly trying to understate it. Among the popular ones, the distros that have switched:

* Fedora
* openSUSE
* Mageia
* Arch

"RHEL may or may not switch in the future."

RHEL 7 is switching to systemd as well

http://rhsummit.files.wordpress.com/2012/03/burke_rhel_ro...

Debian hasn't switched and is evaluating systemd along with OpenRC. Ubuntu has no plans to switch at this point.

Bazaar on the slow track

Posted Sep 12, 2012 21:39 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

and Gentoo and Slackware are not switching in the near term

your info about RHEL conflicts with other posters here.

Yes, several popular desktop distros have switched to systemd, that's far from the "everyone has switched, except for those lone wolves at Ubuntu who refuse to go along with everyone else" mantra that is being pushed.

Bazaar on the slow track

Posted Sep 12, 2012 21:55 UTC (Wed) by Jonno (guest, #49613) [Link] (9 responses)

> your info about RHEL conflicts with other posters here.
Yes, but he is the only one backing it up with sources...

> that's far from the "everyone has switched, except for those lone wolves at Ubuntu who refuse to go along with everyone else" mantra
Correct, but that is not what is being claimed here. What is claimed is that everyone but Ubuntu is either staying with sysvinit (or sysvinit + OpenRC) *or* are moving to systemd, no one else is staying with, or moving to, upstart.

Bazaar on the slow track

Posted Sep 12, 2012 22:17 UTC (Wed) by dlang (guest, #313) [Link] (8 responses)

do you really think that if Debian abandons upstart for OpenRC that Ubuntu will not follow along?

and if Debian remains with upstart (even if they replace the sysvinit option with OpenRC), then Ubuntu sticking with upstart is just staying with the upstream option.

Bazaar on the slow track

Posted Sep 12, 2012 22:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

" your info about RHEL conflicts with other posters here."

I have given you a public source from the company's roadmap slides presented in the company conference and your answer is this embarrassing hand waving?

" do you really think that if Debian abandons upstart for OpenRC that Ubuntu will not follow along?"

This is a poorly phrased question. Debian is not using Upstart now by default. So there is no real question of them abandoning it and yes, Ubuntu might very well decide not to follow if Debian decides to switch to OpenRC or Systemd considering how much they have invested in Upstart and that is quite understandable. Ubuntu has done considerably different things from Debian in many ways including the installer, Unity etc and there is no reason to automatically assume they will follow Debian in this case.

Bazaar on the slow track

Posted Sep 13, 2012 0:06 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

> Debian is not using upstart now by default.

actually, if I do an upgrade of a Debian system, it prompts me to convert to upstart from a sysv init. If this isn't using upstart by default, what is it?

Bazaar on the slow track

Posted Sep 13, 2012 2:52 UTC (Thu) by guillemj (subscriber, #49706) [Link] (3 responses)

> > Debian is not using upstart now by default.

That's right.

> actually, if I do an upgrade of a Debian system, it prompts me to convert to upstart from a sysv init. If this isn't using upstart by default, what is it?

The upstart package in Debian is not Essential, it's not on the base system either (Priority extra), and there's nothing except for live-config-upstart depending on it. So if it's being pulled in on an upgrade that's most probably some third party package doing that, either that or it got selected for upgrade at some point?

Bazaar on the slow track

Posted Sep 13, 2012 2:59 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

I ran into it on the raspberry pi debian image. installing it and doing apt-get update; apt-get upgrade includes getting a question along the lines of "this upgrade will switch you to a dependancy based init, this cannot be reversed, do you want to do this" I'm assuming that this is moving to upstart.

Bazaar on the slow track

Posted Sep 13, 2012 3:00 UTC (Thu) by clint (subscriber, #7076) [Link] (1 responses)

No, that is insserv, which comes from SuSE.

Bazaar on the slow track

Posted Sep 13, 2012 20:21 UTC (Thu) by Tester (guest, #40675) [Link]

And interestingly, OpenSuSe is also going the systemd way

Bazaar on the slow track

Posted Sep 13, 2012 2:59 UTC (Thu) by clint (subscriber, #7076) [Link]

There is no way an automatic upgrade should install the upstart package for you.

Bazaar on the slow track

Posted Sep 13, 2012 18:23 UTC (Thu) by smurf (subscriber, #17840) [Link]

You misunderstand. It asks you whether to switch to a dependency-based (i.e. possibly-in-parallel) execution sequence of init jobs. That's a somewhat more intelligent version of sysv-rc, but it's still sysv-rc, not upstart or systemd or whatever.

Anyway, there are upstart and systemd packages in Debian.
I don't know about upstart, but systemd works really well there.

Debian is probably going to do its usual thing and support both systemd and sysv-rc and/pr openrc and probably upstart long-term -- if for no other reason that tthe fact that systemd contains too many Linux-specific bits and pieces; debian wants to be able to run on top of FreeBSD kernels.

Now let's drop this side discussion and go back to VCS bashing please. ,-)

Bazaar on the slow track

Posted Sep 13, 2012 21:15 UTC (Thu) by zooko (guest, #2589) [Link] (9 responses)

bzr predated git just as upstart predated systemd. Now, maybe one could argue that, having already paid the cost of creating bzr, Canonical should be quicker to cut its losses and switch to git, but that's a lot different from accusing them of unnecessarily creating an alternative. bzr and upstart were first!

Bazaar on the slow track

Posted Sep 14, 2012 14:30 UTC (Fri) by smurf (subscriber, #17840) [Link] (8 responses)

I didn't say that Canonical were not first w/ bazaar and upstart (if my wording implied that, this was not my intent). At least not in absolute terms.

But you need to look at the actual use cases.

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back." So git was the first DVCS that aktually worked for the "impatioen kernel developer" use case.

Or take systemd. Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.
Compared to upstart, sysv-init is good enough for me -- so why bother to switch to it? Compared to systemd, it no longer is. Conclusion: all my systems now boot with systemd. It's not the first init replacement out there, but it's the first worth switching to if you've done it the "/etc/init.d/foo start" way for the last 20 years (which, surprise, continues to work just fine with Debian's systemd).

I am not the only person out there who has written a whole bunch of software (some of whichtook a significant heap of my time+effort+money), which was "good enough" -- but then somebody else took a look at it, said "cool, but I can do better", did better -- and shared their code with me. So why should I not toss my code into the Great Bitbucket in the Sky, and use theirs (and then improve *that* instead of playing catch-up)?

I'm not going to let my ego get in the way of getting things done. Life's too short for that.

Bazaar on the slow track

Posted Sep 14, 2012 14:51 UTC (Fri) by paulj (subscriber, #341) [Link] (6 responses)

Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.

Though, there's no pressing reason why that job must be done by init…

Bazaar on the slow track

Posted Sep 14, 2012 16:23 UTC (Fri) by apoelstra (subscriber, #75205) [Link] (5 responses)

> Though, there's no pressing reason why that job must be done by init…

Well, init is the job's parent, so it's uniquely positioned to notice when a job crashes -- and since init started the job, it's also uniquely qualified to /re/start it.

Bazaar on the slow track

Posted Sep 14, 2012 17:51 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

Well, no, you can trivially have other process managers in between init and your service processes. You could have one that was dedicated to network services, hey it could even handle opening the sockets, watching them and only launching the actual services if there was activity (sound familiar?). You could have another that was specialised to watch TTY lines (Novell UnixWare had one of those I think). You could have another one for whatever.

Or you can have a kitchen-sink system, where you put all this into init, and it has to support every possible need any kind of service will ever have.

Bazaar on the slow track

Posted Sep 14, 2012 18:27 UTC (Fri) by bronson (subscriber, #4806) [Link] (3 responses)

Oo, hey! A micro vs. monolithic argument! Let's all voice our meaningless opinions.

Bazaar on the slow track

Posted Sep 14, 2012 20:07 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

FWIW, I'm not taking a side. Just noting that both ways are possible. :)

Bazaar on the slow track

Posted Sep 16, 2012 3:16 UTC (Sun) by bronson (subscriber, #4806) [Link]

Oh, ok. Can't disagree with that!

QotW material

Posted Sep 18, 2012 22:04 UTC (Tue) by man_ls (guest, #15091) [Link]

I would like to nominate your comment for "Quote of the week" for distributions, if it is not too late. It is sarcastic, it has the LOL factor, and it is true as life.

Bazaar on the slow track

Posted Sep 17, 2012 9:11 UTC (Mon) by pboddie (guest, #50784) [Link]

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back."

I'm pretty sure Mercurial was developed for working with the kernel sources.

Bazaar on the slow track

Posted Sep 26, 2012 10:00 UTC (Wed) by makomk (guest, #51493) [Link] (1 responses)

Ubuntu are hardly the first distro to go off on their own with their init system, though. The days Debian's using a weird dependency-driven system (apparently derived from OpenSuse?), and Gentoo's pretty much always had its own init system (though I think some of its tools are Debian-derived). Once you've got something that's actually dependency-driven, switching to systemd suddenly starts to look a lot less worthwhile.

Bazaar on the slow track

Posted Sep 26, 2012 14:38 UTC (Wed) by smurf (subscriber, #17840) [Link]

I beg to differ; there are a couple of other good reasons why systemd is a good idea.

Before: "Owch, the job failed to start. Now which syslog file did it log its error message to? Oops, it was stderr, so hack the initscript; lather,rinse,repeat".
After: "systemctl status NAME.service"

Before: "This job needs to auto-restart when it dies for whatever reason. Write a hacky wrapper which utterly fails to *not* restart the thing when it *should* die."
After: "This job needs to auto-restart? Add a single well-documented line to the .service file."

And so on.

Bazaar on the slow track

Posted Dec 9, 2012 20:16 UTC (Sun) by jelmer (guest, #40812) [Link]

You could argue that Canonical should give up on Bazaar because that's what the majority of FOSS projects is using nowadays, but not that they started Bazaar for the sake of it. Bazaar predates Git.

Git and Mercurial were both started after the BitKeeper fiasco sometime around March 2005. bzr was already well underway in February of that year; http://sourcefrog.net/projects/bazaar-ng/doc/news.html

Bazaar on the slow track

Posted Sep 18, 2012 11:31 UTC (Tue) by faassen (guest, #1676) [Link] (1 responses)

Nice bit of info here "Also, Launchpad and Bazaar have never really been meant as products in their own right, but more as facilities to build Ubuntu."

Canonical tried pretty hard to get projects in my little community (Zope) to join Launchpad, and also tried pretty hard to get the Zope developers to convert their repository from SVN to Bazaar. So is this "never really meant as products in their own right" a nice bit of historical revisionism, or was this the plan all along and nobody told us?

Bazaar on the slow track

Posted Sep 18, 2012 15:19 UTC (Tue) by pboddie (guest, #50784) [Link]

Maybe the sentiment was that Canonical could not wait for appropriately usable solutions to emerge or become dominant in the areas of version control (Bazaar, in its different forms) and project collaboration (Launchpad), and so they set out to make their own solutions as part of a larger endeavour.

Unfortunately, with Unity being the other prominent example, they don't have a great record of getting people on board or outperforming the other projects in those fields. And so the gamble of striking out on their own hasn't paid off as much as might have been expected.

Bazaar code metrics

Posted Sep 19, 2012 15:45 UTC (Wed) by jermar (guest, #86674) [Link] (2 responses)

Ohloh provides a useful comparison between Bazaar, Mercurial and Git based on accurate code metrics. From there, it follows that Bazaar has had the fewest developers in total and also during the past 12 months. But surprisingly, the code activity (2589 commits) produced by its 35 contributors last year is much higher than the activity produced by Mercurial's 115. It's rather closer to what Git's 200 contributors did during the past 12 months. The trend of lines-of-code is kind of logarithmic, but so is Git's. From these statistics, there appears to be a drop in number of developers and commits, but given the absolute numbers above, it's probably nothing dramatic.

Bazaar code metrics

Posted Sep 19, 2012 16:49 UTC (Wed) by bronson (subscriber, #4806) [Link]

Interesting! It looks like Bazaar is seeing a lot of churn?

                 bzr             hg              git
Lines Added	 658,329 lines	 107,171 lines	 830,470 lines
Lines Removed	 332,498 lines	 39,803 lines	 268,636 lines

Also, the 30 day numbers are currently telling a different story than the 12 month numbers.

Still, overall, that's impressive work per capita by the bzr developers.

Mercurial mostly written in Perl?

Posted Sep 22, 2012 13:02 UTC (Sat) by robinst (guest, #61173) [Link]

It's pretty funny that the Ohloh comparison shows Mercurial to be "Mostly written in Perl"! The same is also shown on the language details for Mercurial.

Turns out that Mercurial uses something similar to shell scripts with a .t extension for test cases, which the language detector categorizes as Perl. Luckily Ohcount, the library which does the counting, is on GitHub, so I submitted a pull request to change that.