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

161–170 of 317 posts

Re: Bzr is dying; Emacs needs to move

#161

Post by chx »

dasil003 wrote: post #125
wirrbel wrote: post #91

Earlier quoted context omitted.

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 ma…

> the desire to support arbitrary workflows.

Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch.

git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.

Re: Bzr is dying; Emacs needs to move

#162

Post by chebucto »

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…

As he said, 'more than Emacs is at stake here.'.[1]

I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to.

Regardless, he has since OKd the switch from bzr:

I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2]

[1] https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00... [2] https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...

edit: formatting

Re: Bzr is dying; Emacs needs to move

#164

Post by dded »

sigzero wrote: post #44
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

If Tcl Core wanted to move to git, Fossil exports repos to that format. So they really lost nothing. They have a small team of commiters as well so Fossil works just fine for them.

A very smart move by Fossil--it makes it safe to try. There's a path out.

Re: Bzr is dying; Emacs needs to move

#166

Post by pseut »

mjs wrote: post #53
sigzero wrote: post #44

Earlier quoted context omitted.

If Tcl Core wanted to move to git, Fossil exports repos to that format. So they really lost nothing. They have a small team of commiters as well so Fossil works just fine for them.

Well, there's also the "social and signaling effects" of using something that's non-git, that Eric S. Raymond articulates well: "we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking."

But that was more about bzr's trajectory than its popularity. My (uninformed) impression is that Fossil is niche but actively maintained.

Re: Bzr is dying; Emacs needs to move

#167

Post by stcredzero »

mjs wrote: post #53
sigzero wrote: post #44

Earlier quoted context omitted.

If Tcl Core wanted to move to git, Fossil exports repos to that format. So they really lost nothing. They have a small team of commiters as well so Fossil works just fine for them.

Well, there's also the "social and signaling effects" of using something that's non-git, that Eric S. Raymond articulates well: "we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking."

Well, there's also the "social and signaling effects" of using something that's non-git

The "not a field" of Computer Programming, to appropriate Alan Kay's quip, is so broken that "social and signaling effects" swamp actual facts and information to a degree that makes it look like Astrology. I've been watching this for decades now -- literally.

Dynamic languages were for years after still tarred with being "slow" when both Moore's Law and progress in JIT VMs and generational GC had make them perfectly fine for tons of applications. If the half-life of patently false misinformation is literally about a decade, and what passes as fact between practitioners is less fact than school rumors, what does that say about our "field?"

Re: Bzr is dying; Emacs needs to move

#168

Post by lstamour »

stiff wrote: post #141
jedrek wrote: post #126

Earlier quoted context omitted.

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.

Stallman doesn't have much influence on Emacs development itself anymore, but Emacs is a GNU project, Stallman is still the head of GNU, and a move to another VCS would be a major organizational change. I too wish he would be less hard-headed about this, but lets not overblow this issue out of proportion.

In replies, he says he doesn't oppose the move to git. Most devs who've replied support git. There's already a mirror. Let's not make mountains out of molehills...

Re: Bzr is dying; Emacs needs to move

#169

Post by StavrosK »

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…

> It turns out however that Git is really easy to grasp.

Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.

Re: Bzr is dying; Emacs needs to move

#170

Post by bronson »

alok-g wrote: post #119
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.

>> 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. Is this an example that goes against the common advice to launch an MVP fast to test the market (and then keep on improving)? It seems that the advice is valid only when there is nothing for the customer to compare the to-be-launched product to. If…

Well, as this article implies, a lot of people don't consider bzr's speed minimally viable.
Post reply on HN