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

141–150 of 317 posts

Re: Bzr is dying; Emacs needs to move

#141

Post by stiff »

jedrek wrote: post #126
stiff wrote: post #116

Earlier quoted context omitted.

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.

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.

Re: Bzr is dying; Emacs needs to move

#142

Post by ableal »

midas007 wrote: post #2

Duplicate of https://news.ycombinator.com/item?id=6999094

Curiously, the URL seems exactly identical in both submissions, which are almost consecutive ( ...94, ...96).

That probably means the duplicate detector has some delay on getting its past submissions data. The rate of submissions these days seems to average one a minute, but the delta on this pair may be different, and it is not apparent by now.

Re: Bzr is dying; Emacs needs to move

#143

Post by jeltz »

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…

Git was also early to the market, but had a fast core and terrible user interface. Git was used for the Linux kernel only two months after Linus had started coding.

Re: Bzr is dying; Emacs needs to move

#144

Post by cjp »

anonymouz wrote: post #117
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 ac…

Here [1] is a good but necessarily incomplete summary of version control tool history, written by ESR.

Tom Lord does deserve much credit for DVCS concepts, but so do Larry McVoy (Bitkeeper) and Graydon Hoare (Monotone).

[1] http://www.catb.org/esr/writings/version-control/version-con...

Re: Bzr is dying; Emacs needs to move

#145

Post by bunderbunder »

dustinupdyke wrote: post #49
EnderMB wrote: post #46

Earlier quoted context omitted.

I've noticed this, oddly, while my workplace is transitioning to git from Mercurial. A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. It's why I always preferred using Mercurial. A few .NET shops that use TFP/VSO are moving towards Git for the Visual Studio support, but I've noticed a few Python and PHP developers making the switch to Mercurial. To be…

It seems that most .NET devs prefer something baked straight into Visual Studio and my experience has been that this is part of the problem in getting those teams to migrate to Git, which is most powerful from the command line. Personally, I greatly prefer my source control system to be separate from my development environment or IDE.

Git's pretty well baked straight into Visual Studio now that it's built into the latest version of Team Foundation Server.

Mercurial's the one where you really want to be using it from the command line. It's had VS plugins, but they're all kind of janky by comparison.

Re: Bzr is dying; Emacs needs to move

#146

Post by belluchan »

lmm wrote: post #81
xradionut wrote: post #42

Earlier quoted context omitted.

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…

> Vim did win the war; there's still nothing better

I'll just put this here for you:

https://code.google.com/p/vim/source/browse/src/eval.c

Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways.

> (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last).

Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.

Re: Bzr is dying; Emacs needs to move

#147

Post by frenchy »

twoodfin wrote: post #80
sillysaurus2 wrote: post #25

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. Bet bitkeeper regretted that decision...

If I recall, the zeitgeist then was that bitkeeper was a necessary evil. My guess is that git would have come into being eventually in any circumstances short of bitkeeper becoming free software, and maybe even then. Distributed change management is such a critical component of the kernel development process (especially for Linus and the other maintainers) that relying on someone else's software seems suboptimal.

The reason Bitkeeper dropped the kernel was that certain kernel devs had started writing free software to interact with the kernel repository (they wanted to be able to perform certain tasks that bitkeeper couldn't). Had this continued, we would probably have ended up seeing a free version of Bitkeeper.

Re: Bzr is dying; Emacs needs to move

#148

Post by cwyers »

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.

But popularity is one of the merits a software package can possess. Popularity offers:

* A wider availability of resources -- tutorials, books, documentation of any kind, a community around the software that can offer help and support to new users, related tools and add-ons. * Evidence of the potential for longevity in the software -- the more popular it is, the more likely it is to continue to receive new features and bugfixes. * Portability of the knowledge of the workings of the software -- for users, this means that investing time and energy into learning the software now is a better investment, because that learning has a higher likelihood of being useful down the road. For people running projects, it means a larger pool of people who already have knowledge useful to contributing to your project.

Your statement basically translates to, "I wish people would use software based on hypotheticals, rather than an evaluation of what it's like to actually use that software."

Re: Bzr is dying; Emacs needs to move

#150

Post by sobkas »

pcx wrote: post #19

Here is a previous discussion on emacs-devel from Mar'13 http://lists.gnu.org/archive/html/emacs-devel/2013-03/thread... Stallman's opinion on this subject - http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg009... TLDR Stallman doesn't want Emacs to give up on bzr (also a GNU project) yet. This opinion might change now though.

rms made a choice: http://news.gmane.org/find-root.php?message_id=%3cE1VyjpD%2d...
Post reply on HN