Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

Post reply on HN
Print view View original

121–130 of 317 posts

Re: Bzr is dying; Emacs needs to move

#121

Post by unethical_ban »

jwr wrote: post #26
gizmogwai wrote: post #15

Earlier quoted context omitted.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

I'd say git is popular not just because of Linus, but also because it is oriented towards "just getting stuff done", rather than towards theoretical concepts. You can rewrite history, fix your mistakes, and generally do whatever you want. When merging, git isn't picky, either: if the code looks the same, it is the same. In-place branching is hugely useful, just switch your tree in an instant (your editor should updat…

Except bzr is conceptually easier to learn and has a more consistent command syntax than git.

Re: Bzr is dying; Emacs needs to move

#122

Post by jordigh »

riquito wrote: post #39
gizmogwai wrote: post #15

Earlier quoted context omitted.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

Git was by far the fastest, this was a big factor when evaluating the move from svn (or similar) to a new system.

Not at all, early git was way slower than early hg. For some operations, e.g. cloning, got is still way slower.

Re: Bzr is dying; Emacs needs to move

#123

Post by rcthompson »

rbanffy wrote: post #67
mickeyp wrote: 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.

With a repository the size of Emacs, it matters. Look at some of the other comments on this article here on HN, where people note that trivial bzr commands on the Emacs repo take way too long to run.

Re: Bzr is dying; Emacs needs to move

#124

Post by leoc »

Someone wrote: post #90
thearn4 wrote: post #84

Earlier quoted context omitted.

Just read the link to Stallman's opinion - side question: he signs his name with a Dr. prefix. But did he finish graduate school at MIT?

According to http://en.wikipedia.org/wiki/Richard_Stallman , he has 14 honorary doctorates and professorships.

It's considered seriously naff to title yourself Dr. on the strength of an honorary doctorate, though — at the very least, you should add "honoris causa". (Even with an earned doctorate you're supposed to avoid referring to yourself as Dr. Smith, in the same way that you shouldn't introduce yourself as Mr. or Mrs. Smith.) Not that I'd really grudge the title to RMS though, who's done more technical hard work and innovation than many people who are running around with earned PhDs.

Re: Bzr is dying; Emacs needs to move

#125

Post by dasil003 »

wirrbel wrote: post #91
falcolas wrote: post #59

Earlier quoted context omitted.

As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.

The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly b…

Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows.

Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined.

After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.

Re: Bzr is dying; Emacs needs to move

#126

Post by jedrek »

stiff wrote: post #116
hyperpape wrote: post #83

I went back and looked at the older discussion, and it doesn't paint Stallman very well as the head of a project. He pins the question of whether to keep using bzr not on whether it is good or whether the Emacs developers want it, but on whether it's being "maintained". But then he seems to define maintenance as having fixed a specific bug that's been around for over a year, blocking a point release. He admits that h…

I think this is more inertia than anything else. It is pretty obvious that Stallman isn't the easiest person to talk to, but he has consistently put huge amount of efforts into GNU for lots of years, and, whatever he did as the maintainer, seems to have worked out pretty much in the end. If there was anyone as active in the Emacs community today as Stallman was in his prime, they could easily push through changes des…

The popularity of a specific fork of Emacs is a moot point, it's the popularity of Emacs as an editor (or should I say, as a platform?) that is at issue. Stallman was active, how that he's not active he needs to either defer to people who are active or watch as fewer and fewer people take advantage of his work.

Re: Bzr is dying; Emacs needs to move

#127

Post by MBCook »

jordigh wrote: post #122
riquito wrote: post #39

Earlier quoted context omitted.

Git was by far the fastest, this was a big factor when evaluating the move from svn (or similar) to a new system.

Not at all, early git was way slower than early hg. For some operations, e.g. cloning, got is still way slower.

But most people were comparing it to CVS or SVN, and it was much faster than those.

Re: Bzr is dying; Emacs needs to move

#129

Post by sophacles »

davidw wrote: post #36

The Tcl guys are in a similar situation - they use Fossil. Which by all accounts looks pretty cool, but at this point it's "not git". http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

Something I've wanted to see for a while is a fossil-like wrapper system for git. The idea of keeping bug tracking and wiki as part of the repo makes a lot of sense.

Re: Bzr is dying; Emacs needs to move

#130

Post by vidarh »

rbanffy wrote: post #67
mickeyp wrote: 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.

It's about lowering the threshold so that when I need to patch your project, I can trivially clone the repo with software I already have installed and know, do my change, commit and create a patch or submit a pull request to Github or whatever with so little extra hassle that I feel compelled to do so rather than just making the change to my local tar-ball and never upstreaming the changes unless/until there's something large enough to be a pain to maintain separately.

Frankly, that ability is more important than the choice of DVCS: There's more value from most people standardising than in picking the "optimal" DVCS just because of the lowered barriers to participation.

Post reply on HN