Bzr is dying; Emacs needs to move • Hacker News Board

Re: Bzr is dying; Emacs needs to move

#221

Post by Crito » Thu, Jan 02, 2014, 8:39 PM UTC

lmm wrote: post #215

Crito wrote: post #184

Earlier quoted context omitted.

> "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" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.

I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine…

Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to.

I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through.

It isn't the way that I prefer using git, but it works perfectly well.

Re: Bzr is dying; Emacs needs to move

#222

Post by unethical_ban » Thu, Jan 02, 2014, 8:41 PM UTC

andrewem wrote: post #199

unethical_ban wrote: post #121

Earlier quoted context omitted.

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

What are some of the conceptual differences that make bzr easier to learn? (I agree that git's command syntax is inconsistent.)

The syntax is part of it being easier. Also, though it's been a while since I tried using any official git documentation, bzr's website had handy tutorials, references, and cheatsheets available. Great layout, assumed no VCS experience.

Re: Bzr is dying; Emacs needs to move

#223

Post by asveikau » Thu, Jan 02, 2014, 8:43 PM UTC

Demiurge wrote: post #216

justincormack wrote: post #205

Earlier quoted context omitted.

Because building and maintaining a competitive OS is a huge effort, and FreeBSD has lots of cool stuff which they can't use...

It's a huge effort worth that seems to be paying off quite handily. XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned. FreeBSD has plenty of cool stuff, but in a completely different domain.

> XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned.

This seems a bit delusional. I don't think it's controversial to say that Apple's biggest differentiators exist at higher levels than kernel space. I'd go so far as to say that anyone who claims that Apple's success is rooted in XNU and that the same could not have been done with Linux or *BSD at the lowest layer and all other pieces being equal does not understand what a kernel is.

Re: Bzr is dying; Emacs needs to move

#224

Post by mempko » Thu, Jan 02, 2014, 8:43 PM UTC

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

the exchange made lucid seem like a bunch of assholes

Re: Bzr is dying; Emacs needs to move

#225

Post by aaronem » Thu, Jan 02, 2014, 8:45 PM UTC

agumonkey wrote: post #213

aaronem wrote: post #114

Earlier quoted context omitted.

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

Lisp systems legacy I suppose, the core is ~tiny, everything else is a library.

Sorry, I was unclear; by "core" I mean "the Emacs distribution itself", as opposed to libraries you find on Github, EmacsWiki, or wherever else that isn't part of the standard Lisp library you get when you download the Emacs tarball.

Re: Bzr is dying; Emacs needs to move

#226

Post by aaronem » Thu, Jan 02, 2014, 8:46 PM UTC

justincormack wrote: post #205

Demiurge wrote: post #191

Earlier quoted context omitted.

Why would they do that? Mach allows for some cool stuff, like kernel extensions being isolated.

Because building and maintaining a competitive OS is a huge effort, and FreeBSD has lots of cool stuff which they can't use...

Darwin + Aqua also has lots of cool stuff which *BSD can't use. I can see a competitive advantage in making sure that remains the case.

Re: Bzr is dying; Emacs needs to move

#227

Post by binarycrusader » Thu, Jan 02, 2014, 8:50 PM UTC

bitwize wrote: post #208

binarycrusader wrote: post #152

Earlier quoted context omitted.

Yep, I don't understand the author's assertions about Mercurial either. Mercurial remains a better choice for a few use cases where git simply falls flat. Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. And realistically, perforce or other solutions appear to be even more popular among…

Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.

  Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.

Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4.

Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a large following among the corporate world. And many of the largest tech companies I'm aware of don't use p4 primarily; they use git, mercurial, svn, cvs, SourceSafe, home-grown solutions, etc.

Re: Bzr is dying; Emacs needs to move

#228

Post by Demiurge » Thu, Jan 02, 2014, 8:51 PM UTC

comex wrote: post #217

Demiurge wrote: post #214

Earlier quoted context omitted.

They're isolated enough that drivers can crash and just be reloaded, without a kernel panic.

No, they are not. A crash in a kext causes a kernel panic.

You are right. An actual crash in kext causes kernel panic. I think I read that this is was possible, but I can't find how, and when, right now. The common thing that I'm thinking of is just voluntary error (exception) handling in kexts and reloading of kext on their own. There is some isolation and benefit to it.

Edit: ok, I just figured out my source of confusion. IOKit allows userspace drivers, which can crash without resulting in panic.

Re: Bzr is dying; Emacs needs to move

#229

Post by ecspike » Thu, Jan 02, 2014, 8:53 PM UTC

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?

Long answer yes with a but. They will eventually take up the mantle from devs who age out or die. We might have something totally different than Git at that point but it's not good to dismiss them either. That is how projects die.

Re: Bzr is dying; Emacs needs to move

#230

Post by belluchan » Thu, Jan 02, 2014, 8:55 PM UTC

lmm wrote: post #207

belluchan wrote: post #146

Earlier quoted context omitted.

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

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

No Objective-C was not dead before iOS. A thriving Apple was supporting Objective-C in every way possible, and moving from Carbon to Cocoa.

Objective-C is used to build applications for Apple software. It's not a threat to Java, but that doesn't mean Objective-C is dead. Objective-C will be around for a long time to come. It's a modern language that powers all of Apple's most recent technology. They have no reasons to change, and there are no signs that Apple is on the verge of disappearing into the aether.

Vim is shitty software. I like the UI, but the thing is single threaded and everything runs on the UI thread. There's no hope for async, or an event loop, or even a settimeout like feature. The code is full of globals and trying to add new features to the thing is going to result in inexplicable, unfathomable seg faults. Vim uses shitty regular expressions in the UI thread to do syntax highlighting which is why that's slow for big files and why the syntax highlighting breaks.

So the code matters. There will never be powerful IDE like features as long it's this single threaded thing that only ever does anything as a response to user input. Given the state of the code, changing this does not seem ever possible.