19 ms·
Bzr is dying; Emacs needs to move
- midas007 13y agoDuplicate of https://news.ycombinator.com/item?id=6999094 https://news.ycombinator.com/item?id=6999094
- ableal 13y agoCuriously, 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.
- __david__ 13y agoI can't tell now that the other one is dead, but I believe it's link was http: while this one's is https:. I use the "https everywhere" browser extension so when I copied the URL I probably got the upgraded one. I think that explains why the dup detector didn't catch it. I don't know why this story took off and the other died. Maybe the headline?
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- djm_ 13y agoFor those wondering: Vim is currently on Mercurial @ Google Code [1] [1] http://www.vim.org/sources.php http://www.vim.org/sources.php
- guns 13y agoAnd happily for git users, the git-hg plugin makes maintaining a git mirror of the vim hg repo very convenient: https://github.com/cosmin/git-hg https://github.com/cosmin/git-hg Submitting patches upstream is also not a problem as Bram Moolenaar only accepts patch files on the dev mailing list.
- graywh 13y agoI'm not convinced Bram actually uses hg in his normal workflow, but provides the repo as a convenience.
- rjzzleep 13y agothe most annoying thing about bzr in my opinion is it's stupid branching model. luckily a migration to git is a oneliner. git init ; bzr fast-export --plain | git fast-import
- icebraining 13y agoluckily a migration to git is a oneliner. I wish. Unfortunately, not all repos we use are owned by us, and using two VCSs is worse than sticking with bzr.
- sergiosgc 13y agoIsn't it possible to track the upstream just like with svn? We use git internally but interact with third party subversion repositories. We do it by dedicating a branch to tracking the svn repo, use git-svn to branch and to push the commits (after rebasing). It's not perfect but after a few hurdles at the beginning it is now problem free.
- crncosta 13y ago"git won the mindshare war" Sad, but true...
- officemonkey 13y agoThey 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.)
- levosmetalo 13y agoGithub 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.
- ghc 13y agoI 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.
- sophacles 13y agoI think there was a co-evolution of the two. A lot of people started using git because Github was where the cool projects were being hosted. At the time, I recall hoping for bzr to "win". I like git these days but coming from an svn is king world - bzr was a bit gentler for transition.
- mateuszf 13y agoWhat's so sad about it? IMHO git is awesome.
- Aqwis 13y agoOddly, 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?
- zobzu 13y agogit 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)
- DigitalJack 13y agofor 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.
- lmm 13y agoWhat do you mean, a python command line client? If you're using it from the command line and not programmatically, why does it matter what language it's written in? (gitless may possibly be what you want)
- pritambaral 13y agoIt matters if you want to hack on it.
- DigitalJack 13y agoportability
- peacetara 13y agohttp://www.samba.org/~jelmer/dulwich/ http://www.samba.org/~jelmer/dulwich/
- dscrd 13y agoYeah, Mercurial is a viable choice still for just about all projects, and most of the time the simpler one.
- stiff 13y agoFWIW, just a few days ago I was browsing through the Emacs Bzr repository - after a full bzr clone, that took ridiculously long as well, a simple bzr blame takes 40-60 seconds to execute locally, and I have an SSD drive, four-core intel i7 and 8GB of RAM. I have never seen this kind of slowness with Git, with any repository size.
- __david__ 13y agoOh yeah, doing anything with bzr and Emacs is just painful. For fun, check your CPU usage while your doing that bzr blame. I did one recently and it pegs at 100% for the whole time. Git is way more efficient.
- mathattack 13y agoDoes this make the issue a critique of RMS's management style, or of the FSF licensing that is unable to back out of a failed project?
- justincormack 13y agoIf you look at the thread, it seems to be neither, just inertia. The licensing is fine, its GPL, no different from bzr.
- drzaiusapelord 13y agoInertia seems to fit with bad management style. Good managers should be fighting it when it becomes cumbersome. Stop making excuses for FOSS celebrities and start demanding better outcomes.
- pcx 13y agoHere is a previous discussion on emacs-devel from Mar'13 http://lists.gnu.org/archive/html/emacs-devel/2013-03/threads.html#00870 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/msg00905.html 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.
- thearn4 13y agoJust 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?
- Someone 13y agoAccording to http://en.wikipedia.org/wiki/Richard_Stallman http://en.wikipedia.org/wiki/Richard_Stallman, he has 14 honorary doctorates and professorships.
- leoc 13y agoIt'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.
- noselasd 13y agoWell, he did finish a physics degree at Harvard, which awards Doctor of Science titles
- sobkas 13y agorms made a choice: http://news.gmane.org/find-root.php?message_id=%3cE1VyjpD%2d0003mS%2d18%40fencepost.gnu.org%3e http://news.gmane.org/find-root.php?message_id=%3cE1VyjpD%2d...
- mickeyp 13y agoThe 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.
- rbanffy 13y agoCompared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.
- mickeyp 13y agoTen (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?
- joelthelion 13y ago>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?
- Goosey 13y agoAbsolutely. Stigma over a (d)vcs !== (in)ability to contribute to a project.
- sparkie 13y agoI wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.
- reddit_clone 13y ago
- bachback 13y agowow. 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.
- tobiasu 13y agoThe command preceding this outburst was: $ sudo braindump bachback.core|tail ;-)
- bachback 13y agohaha. I've actually spend time trying to read emacs's source code. I guess the downvoters haven't.
- swah 13y agoI agree - Emacs has to be rewritten on top of a modern rendering engine!
- saalweachter 13y agoThey did. It is called 'Eclipse'.
- sixthloginorso 13y agoJust not the same. Adding functionality to Eclipse is a "project". In Emacs, it's just some code and an eval-last-sexp away.
- rbanffy 13y agoThen do it.
- swah 13y ago
- davidw 13y agoThe 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 http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
- sigzero 13y agoIf 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.
- davidw 13y agoIt's more about attracting people with an easy barrier to getting involved. Granted, it's not really that big a deal (IIRC there are github mirrors), but it is an obstacle.
- mjs 13y agoWell, 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."
- pseut 13y agoBut that was more about bzr's trajectory than its popularity. My (uninformed) impression is that Fossil is niche but actively maintained.
- stcredzero 13y agoWell, 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?"
- tenfingers 13y agoI 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.
- auvrw 13y ago> 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?
- rlpb 13y agoPopularity means developers, which means bugfixes and more features in the future which projects may want to use. Switching DVCS has a cost to a project. Thus software popularity is important. This may be unfortunate, but this is how it is. DVCSs are by no means complete today, and cross-pollination of features continues. An unpopular project that has fewer developers working on it will fall behind. A project that doesn't want to keep switching DVCS has a reasonable interest in the DVCS project's future, since future features will come "for free".
- octo_t 13y agopart of something's merits is its popularity.
- acdha 13y ago> 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.
- mikro2nd 13y ago>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses? I believe that much of the popularity of git stems from github making it very easy to adopt, something that bitbucket doesn't seem to have pulled off as well.
- xradionut 13y agoI 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?
- falcolas 13y agoAs 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.
- wirrbel 13y agoThe 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 become quite complicated and in the end it is hard for the user to get a deeper understanding of the system. The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
- dasil003 13y agoExactly. 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.
- popey 13y ago"most of Canonical's in-house projects have abandoned bzr for git". Nope. Unity, Mir, Upstart, all of the new phone/tablet apps and platform tools are on bzr on launchpad. Not disputing the fact that git has won the war, just nitpicking that point.
- harel 13y agoI'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.
- rmrfrmrf 13y agoIt'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.
- hyperpape 13y agoI 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 he can't follow the developers list to see if they're genuinely doing active maintenance (reasonable enough: he has a lot on his plate), but also won't accept the testimony of Emacs developers that the mailing list is dead and there's no evidence of real maintenance. When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all. But the proposed replacement is GPL software. This is just madness. Refs: http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00906.html http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg009.... http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00870.html http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg008... (and surrounding posts).
- blumentopf 13y ago> 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 http://www.jwz.org/doc/lemacs.html
- hyperpape 13y agoshrug More confirmation.
- vezzy-fnord 13y agoNot to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.
- IgorPartola 13y agoThat's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically. Imagine if Stallman and co. managed to convince a good number of developers that it was a good idea and the kernel was competitive with Linux, BSD's, etc. If you believe you have a technically superior vision for your product, should you compromise on it just because people who do not share in your vision will not join you? In the end, I think what killed the pure GNU/Hurd OS was bad PR and absolutism. Hurd as a technical question was just a small part of that. Remember, the debate between the Free and the Open Source guys was pretty fierce. Today we use terms like FOSS to describe all open software, but when Linux and Hurd were young these were different camps with opposing philosophies, and the one that appealed to more developers won out. In simplistic terms, you can think of this as the VHS vs Betamax debate. Can you blame the Betamax backers for continuing to try to push it and "killing" it as a result?
- TacticalCoder 13y agoMany Emacs contributors are already using Git and simply publishing everything in Github. Most of the things in my .emacs comes from Github. Simply they're not part of the core Emacs. I think the issue is not only bzr vs Git. It's also, if I understand things correctly, the super restrictive license that the core Emacs has, making every developer sign papers and send them (by snailmail!? or are scans allowed!?)... And if you several other contributors helping you, you must have them all sign these papers. I've seen at least one prolific .el Emacs author (I think the mulled/multi-line-edit author) complain about that: saying that out of 10 people who helped him he managed to have nine of them sign the papers and sent them to him and couldn't contact the last one... And eventually he simply decided to abandon getting all the signatures and went it's own way (i.e. Github / non-core Emacs, like many do). I'm not well versed in licenses / GPL things but I'm a long time Emacs users and I'm definitely seeing change: now most of the newer (and great) .el files I add to my Emacs are coming from Github.
- sixtypoundhound 13y agoBzr certainly isn't dead. git has won the mindshare war for mainstream developers, but I've found it to be a useful FOSS alternative for developers forced to use a Windows environment [for business-related reasons, don't laugh..it pays the bills]. Their UI is a bit more intuitive than git's for new users. Now, if you're a hardcore Linux-stack career dev...get onto git ASAP... but for lesser folks...bzr works just fine...
- Macha 13y ago> but I've found it to be a useful FOSS alternative for developers forced to use a Windows environment [for business-related reasons, don't laugh..it pays the bills]. Their UI is a bit more intuitive than git's for new users. However, the same also applies to Mercurial, and even though Mercurial is less popular than Git, it still has a lot more devs who use it than Bzr.
- manish_gill 13y agoI had to interact with bzr last year for my GSoC project (Mailman, hosted on Launchpad). It wasn't a pleasant experience, and got a whole lot more complicated when I had to move a Git repo to LP. Bazaar is bad. :(
- deleted 13y ago[deleted]
- hyperpape 13y agoWell, it looks like it will happen.[1] In light of my other comment, good for Stallman. Seems he wasn't actually so hardheaded as it seemed. [1] https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00014.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
- Beliavsky 13y agoDo people really decide whether to contribute to an open source project based on the version control system it uses, rather than the importance of the project itself?
- codex 13y agoThe entire GNU project is like a house that looked so mod in 1971, but now has peeling paint, stained concrete, shag carpeting that smells pretty funky, and a crazy old relative that haunts the place. "Renovation" is changing the light bulbs and occasionally washing the stucco.
- codex 13y agoIf Emacs moves to git, can we call it by its proper name: git/Emacs?
- kro0ub 13y agoFor those who want to learn BZR and help revive it by adopting it in your projects, there's a nice book here: http://www.foxebook.net/bazaar-version-control/ http://www.foxebook.net/bazaar-version-control/