Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

61–70 of 317 posts

Re: Bzr is dying; Emacs needs to move

#61
post #29
post #7

"git won the mindshare war" Sad, but true...

The article is also mentioning bad state of Mercurial, any idea what he could have had on mind? What's wrong with Mercurial these days, beside its less widely used than Git?

I'm pretty sure Atlassian is the only major supporter of it, and even they co-host Git on BitBucket (I suspect to stay competitive with GitHub).

And in my very biased opinion, Atlassian markets themselves with an aggressively old-school mentality (closed source everything, monolithic software, questionable terms of use, strong force in the enterprise market, etc.), which makes Mercurial look bad by association.

Re: Bzr is dying; Emacs needs to move

#62

wow. please, please, you Emacs/LISP gurus out there: make a working modern package manager and integrate the browser like lighttable does. and perhaps rewrite emacs from scratch so that the source code makes sense in today's world not in 1980's world. unfortunately lighttable is staying closed for much too long, but something like it is desperately needed.

LightTable is truly terrible. Adobe beat that team with Brackets without even really trying, and all of the gimmicks it promised have been available in vim and subl for a while. They should do something else with their time.

Re: Bzr is dying; Emacs needs to move

#63
I'm using bzr on a large scale project and have not experienced any problems. A full fresh branch does take a while to complete but I find it acceptable as we're not branching the full repo from the server that often. Usually its local branches. When using git on a similar scale project we found that we spent a lot more time managing the source control system than we ought to. Source control should be something you rarely worry about and requires no 'management' other then regular usage. Git was not that. Git required effort.

Re: Bzr is dying; Emacs needs to move

#64

Earlier quoted context omitted.

They had two things going for it: * Linus was using it for the kernel, so it became mature slightly faster (because it had more people's attention.) * Github happened at the same time Sourceforge stopped being cool (this is the same time that Digg and Reddit started beating Slashdot.)

Github became popular because people wanted free Git hosting, not the other way around. Most other Github features just get in the way. Also, instant branching are really convenient feature. I remember the time when I was using Darcs that I got lost pretty quickly with 10 copies in 10 directories.

I disagree wrt Github. A lot of projects I was involved in wound up switching from git to mercurial because it was too difficult to manage git master repos on a server compared to Mercurial. Github solved this neatly, and the issue system has allowed my last two companies to switch from Mercurial+FogBugz|Trac to Github. That's useful consolidation and lower admin overhead.

Re: Bzr is dying; Emacs needs to move

#65
post #20
post #8

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?

This is what happened, basically a huge "I told you so, proprietary software blows." for the Stallmans of this world: http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tri...

This is excellent trolling material because you can argue in both directions: It proves proprietary software can't be trusted; and at the same time it proves Open Source is all about free knockoffs of innovations made in proprietary software.

Re: Bzr is dying; Emacs needs to move

#66
It's a bummer to think of all of the real-life dollars that have been sunk into Bzr's development, which I'm sure makes a decision like this harder. That said, isn't this what forking is for? The people who want Git support should code and maintain it themselves.

Re: Bzr is dying; Emacs needs to move

#67
post #24

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.

Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.

Re: Bzr is dying; Emacs needs to move

#68
post #9
post #8

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?

git is used by a bigger project (the kernel), that's mainly why. they're all ok, otherwise, even with their technical differences. github also contributed to amplify the adoption as its makes it really easy to use (even thus people generally use git in a non-distributed way with github) (i do prefer git in usage, tho, but thats subjective i suppose)

for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli.

If Hg were as good at branching and rebasing, I'd reconsider it.

btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.

Re: Bzr is dying; Emacs needs to move

#69

Earlier quoted context omitted.

Git won the popularity war because the Linux kernel used it and then Github pushed it mainstream. Frankly, Bzr never got as popular as Git and Hg because it just isn't as good. It's slow, has a bizarre (sorry) branching model, and came out of Baz and Arch which were downright terrible (to be fair, Bzr shares no code and was designed as a rewrite to jettison all the stupidness of Baz and Arch—nonetheless it is tainted…

Actually I think Github got popular because it was Git, not the other way around. At the time it appeared people just wanted to have git repos, Github was there, so they used it.

Confirming that, Bitbucket added git support because they saw Mercurial as not competitive with Git.

Re: Bzr is dying; Emacs needs to move

#70

I wished people would use software based on merits, not on popularity. That being said, Bzr is slow, it was always slow from day 1 -- and slowness is part of the UI experience.

> I wished people would use software based on merits, not on popularity.

this. so much. but "social and signaling effects" and "mindshare war" instead. sigh. what /is/ true, though, is the quote from the linked article:

"All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection."

anyway, in an attempt to return from the hopelessly abstract and say something cogent about hip technologies and the article at hand, umm... i wonder how bzr runs on pypi?

Post reply on HN