Hacker News new | ask | show | jobs
by abusque 4238 days ago
He's not really actively involved, though. He's just been on a crusade lately to eradicate unwanted VCSs still used in older projects, including CVS for NetBSD and bzr for emacs. Honestly I'm glad he's doing it, I'm hoping it might make it more likely for newcomers to contribute to these projects. He has posted quite a few articles about these conversions on his blog [0], if you want to read about it.

[0] http://esr.ibiblio.org/

3 comments

First I've ever heard of Bazaar (bzr). Sponsored by Canonical.

It's a smidge ironic that ESR himself is migrating a project away from it. :)

There were three distributed VCS that were in the running for a while. There was git, bazaar (bzr), and mercurial (hg). For a while people were using on all 3, but eventually git won out.
In my little experience with bzr, it was slow as molasses. The only competitive advantage it had against Git at the time was a simpler command line and better windows support (we are talking about the days when git commands were still spelled like git-branch, git-reflog and so on.)

Eventually Mercurial ate Bazaar's pie and now Git is slowly eroding projects away from Mercurial. All hail Linus, who managed to create two open source systems that became de-facto industry standards.

Both because of technical itches he wanted scratched.

With Linux it was the ability to use unix without having to stomp over to the university computer lab during the Finnish winter.

With git it was creating something that could handle merging patches from a disparate set of developers.

And, y'know, in short order he'll own the dive log market.
You are forgetting darcs, which IMO is a lot better than bzr and hg.
How does it compare speed-wise with git? That was the reason I switched from darcs 8 years ago. Some of my repos go back over a decade, and darcs had problems with them when there was just two years of history.
There was some issue with exponential running times in certain scenarios. I ran into an issue where two repositories were somehow in a state where a pull would never terminate. darcs definitely had problems.
I don't see the irony. What am I missing?
But he had nothing to do with the development of bzr...
It is more in the lineage of puns and odd coincidences (not quite right, but something better is escaping me)
Its not really completely a coincidence, since The Cathedral and the Bazaar is almost certainly the source of the name of the VCS.
esr knows how much of the open source community's success is driven from social factors as opposed to technical factors. I'm excited with his progress as well.
Wonder if he's tried to evangelize on the OpenBSD mailing lists yet? The smackdown from Theo would be amusing.

To some extent, it's good he's doing this. To another, very few VCSs other than SCSS can really be called "obsolete", just primitive. Most of the time, people who go on about VCS migrations seem to be just bikeshedding and can't seem to give out specific justifications other than listing features that the upstream project likely doesn't need. It's not trivial either, changing a VCS often means changing the entire way a project is structured, for often uncertain gains.

Well, I can pick on OpenBSD's favorite: CVS repository corruption does happen, but CVS has no active integrity checking. You'll only detect it if you go far enough back... or run a conversion program. If you're lucky, you discover while it's covered by backups, but these issues can sleep for years. This caused a migration I was involved with to just become a scrape, as the code at the tip was fine.

(I'd also say that atomic commits are an excellent reason to leave CVS behind, but that can be argued.)

been there, done that, shit seriously sucked

you should never use a vcs that has no ability to ask "is this repo in a valid state", or you may try to checkout the point version released to a large customer and be unable to do so. Data corruption can happen, even on raid drives (we're pretty sure it was a bug in the controller, but that doesn't change the effect.)

He has written a bunch of nontrivial code, and is running that code himself on his own machines (and those donated specifically for this purpose). He leaves it to the community to decide whether they want the products of that work. This seems the antithesis of bikeshedding.
Not waiting for your current VCS to bitrot is probably a good idea (assuming bzr dying isn't massive hyperbole)
It's not hyperbole, development has pretty much ground to a halt: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes