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

111–120 of 317 posts

Re: Bzr is dying; Emacs needs to move

#111

Post by agwa »

eloisant wrote: post #32
__david__ wrote: post #30

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.

There wasn't a demand for Git repos any more than there was a demand for Hg repos. For instance, open source projects moving away from SVN seemed to be pretty evenly distributed between Git and Hg.

The real demand was for a way to publish code and collaborate, and GitHub provided a truly innovative approach (the social aspects, encouraging forking and pull requests) that was miles better than the alternatives (SourceForge was already in decline, Google Code didn't have the social/forking/pull request aspects). I think they would have been successful with any distributed VCS. I always preferred Git, so I'm happy they chose Git, but I think that if they had chosen Hg, we'd be talking about how Hg won the popularity war instead of Git.

Re: Bzr is dying; Emacs needs to move

#112

Post by rlpb »

dded wrote: post #103
rlpb wrote: post #35

Earlier quoted context omitted.

One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using plain text patches on mailing lists for code review, etc. At this stage, isn't a "bzr vs. git vs. hg" question at all. It's just "look, it's a patch". I think this ease and ability to work losslessly with plain text patches gives git a clear advantage over bz…

I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.

To the extent that svn works with patch, so does bzr, and so does git.

What I'm talking about is lossless integration with entire patch sets in the form that git does it with format-patch, send-email and am.

Re: Bzr is dying; Emacs needs to move

#113

Post by agwa »

rbanffy wrote: post #69
eloisant wrote: post #32

Earlier quoted context omitted.

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.

But only after Git became wildly popular because of GitHub.

Re: Bzr is dying; Emacs needs to move

#114

Post by aaronem »

dded wrote: post #108
cpach wrote: post #95

Earlier quoted context omitted.

I thought RMS had resigned as Emacs’ maintainer? http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby. (There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)

An excellent point; for example, although I don't have any reason to think RMS himself did this, Emacs 24.4 will have file change notification support across all platforms where it compiles and where such notifications are available.

I grant that's a somewhat overdue feature for Emacs to have (e.g., I've wanted it ever since I set up Dropbox to synchronize my org-mode files across all my boxes), but it's definitely evidence that Emacs isn't lacking of maintenance and improvement.

I wonder: If Emacs rarely gains new features in core, is it because there aren't enough developers doing enough to improve it, or rather because people are having a hard time thinking up new features to add which Emacs doesn't already have?

Re: Bzr is dying; Emacs needs to move

#115

Post by acdha »

tenfingers wrote: post #38

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 is “your favorite band sucks” for software. For professional tools, popularity is usually directly tied to merits: notice how frequently people say they started with bzr/hg/darcs/etc. and switched to Git because it was faster/safer/better supported/added features they liked? Most of the competitors seemed to think they'd solved one big problem well enough that people would put up with the “minor” warts but in practice those are the things which you notice on a daily basis. Git was the third or fourth DVCS I tried and even fairly early on it was obvious that considerably more care was going into making basic day to day work easier and safer.

Re: Bzr is dying; Emacs needs to move

#116

Post by stiff »

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 despite Stallman's disagreement, via a fork or otherwise, but there isn't such a person, and that is that.

Consider that it has been almost 30 years since GNU Emacs started, for most of this time RMS has been the maintainer, and GNU Emacs continues to this day to be the most advanced, popular and active Emacs there is, while the various forks in existence like XEmacs, SXEmacs lost steam pretty quickly. So it certainly hasn't been all bad on his side.

Re: Bzr is dying; Emacs needs to move

#117

Post by anonymouz »

Aqwis wrote: 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?

Adding a bit of history to the other comments: Bazaar is actually a successor to an earlier DVCS, called Gnu Arch (or Tom Lord's Arch, TLA, at some point). It started out in 2001 and was, I believe, the first of the DVCS crowd. It had some idiosyncrasies, but was a huge step up from CVS in terms of its principles.

tla was forked into baz (previously Bazaar), and bzr (previously Bazaar-NG) was a rewrite taking into account lessons learned from tla/baz. Darcs is yet another DVCS inspired partly by Gnu Arch.

So while the explosion of new DVCS around 2005 can definitely be traced back to the Bitkeeper incident, I believe the seed for modern DVCS was laid a bit earlier, in 2001, with Tom Lord's Arch. I think Gnu Arch/tla is to be credited with originally introducing many of the concepts of distributed version control.

Of course, if anyone knows of earlier history on distributed VCS or a VCS that isn't in some way a spiritual successor to TLA I would be quite interesting in knowing that.

Re: Bzr is dying; Emacs needs to move

#118

Post by Goosey »

joelthelion wrote: post #104
mickeyp wrote: post #77

Earlier quoted context omitted.

Ten (edit: even five!) years ago I'd agree with you. Back then a source control system was a piece of software you used for keeping a versioned history of your work and to enable you to collaborate with coworkers or friends. It was a tool. Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?

>Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on? Do you really want those guys on your project?

Absolutely. Stigma over a (d)vcs !== (in)ability to contribute to a project.

Re: Bzr is dying; Emacs needs to move

#119

Post by alok-g »

gizmogwai wrote: post #15
Aqwis wrote: 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?

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 competing products end up launching at around the same time as yours, the advice may turn its head on you.

Re: Bzr is dying; Emacs needs to move

#120

Post by belorn »

blumentopf wrote: post #87
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…

> it doesn't paint Stallman very well as the head of a project Is this news to you? Cf. e.g. http://www.jwz.org/doc/lemacs.html

I'm not sure that conversation is a good example of what you are trying to describe.

Let's see if someone did the following things to the python project:

1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project.

2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever.

3#: Ignore current list of new feature being worked at. Community goals are unimportant.

4#: Add code regression! Do not care about maintaining performance.

5#: Demand that the changes get implemented immediately in next official release.

Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.

Post reply on HN