GNU Emacs Switches From CVS To Bazaar

kfogel writes "GNU Emacs, one of the oldest continuously developed free software projects around, has switched from CVS to Bazaar. Emacs's first recorded version-control commits date from August, 1985. Eight years later, in 1993, it moved to CVS. Sixteen years later, it is switching to Bazaar, its first time in a decentralized version control system. If this pattern holds, GNU Emacs will be in Bazaar for at least thirty-two years ..."

Comments

Why 32?

[hezekiah957]

24 is plausible, too; an arithmetic not geometric progression.

Re:Why 32?

[Anonymous Coward]

I reckon after two years they'll get bored and switch to keeping commits in directories named gnuemacs.20120415, gnuemacs.working, gnuemacs.old-dontdelete, etc.

Re:Why 32?

[EvanED]

Is there a 'scary' mod? I don't see it in my list unfortunately.

Re:Why 32?

[Anonymous Coward]

Powers of two are much more beautiful. They are appropriate for a software development project. They will also relatively reduce the need to frequently move to new version control systems, as the interval will dwarf human lifetimes as we know them after doubling only a few more times. An arithmetic progression may seem clever now, but what about 8160 years from now? Will it look so smart then? I think not.

Re:Why 32?

[kfogel]

Ok, that's fair -- it could go either way. That's what I get for trying to be too clever!

Re:Why 32?

[ls671]

> Is there a 'scary'

scary mod would be ambiguous with regards to ranking, some horror/apocalyptic movie fans might view as + while some others might view it as - ;-)

Re:Why 32?

[Architect_sasyr]

By that token we have funny-strange and funny-hilarious. Since when did anyone on slashdot fail to be ambiguous?!

Re:Why 32?

[Anonymous Coward]

According to the specs for various conversion tools, you can capture the CVS trunk but not the branches. So most of the emacs history could be lost in the conversion

Re:Why 32?

[fuzzyfuzzyfungus]

Don't be silly. This isn't some spartan text editor like vi.

Future emacs development will be hosted inside emacs, with a version control extension written in emacs lisp.

Re:Why 32?

[Arancaytar]

spartan text editor

THIS! IS! EMACS!

Re:Why 32?

[Kynde]

24 is plausible, too; an arithmetic not geometric progression.

I'm so sorry, but you are utterly wrong.
24 would perhaps be plausible in carpentry or equestrian, or if the numbers were 7 and 14, but in this case, i.e. with software, powers of two and slashdot, there are simply two and only two possible successions to that and those are indeed the 0x20 and some-funky-number-with-cowboyneal-embedded. And that's final. Move along, move along.

Re:Why 32?

[selven]

But what if the powers themselves go along a geometric progression? 2^3, 2^4, 2^5.33...

Re:Why 32?

[Ginger Unicorn]

always amusing

Re:Why 32?

[larry bagina]

some-funky-number-with-cowboyneal-embedded.

I hope that number isn't 69. I've gotta go wash my eyes out with goatse and tubgirl.

Re:Why 32?

[mpeskett]

Let's not forget insightful-popular, insightful-contrarian and insightful-'said they expect to be downmodded'

Re:Why 32?

[sconeu]

Best. EMACS. Comment. Ever.

Re:Why 32?

[sproingie]

Maybe a hierarchy of "funny". Funny-Haha, Funny-Serious, Funny-I-Laugh-Lest-I-Cry ...

first first?

[Tumbleweed]

You'd think there'd be an emacs keystroke combo to check for duplicate words in a block of text.

Re:first first?

[melikamp]

(defun search-dupe-words ()
"Search for word dupes"
(interactive)
(search-forward-regexp "[^a-z]\\([a-z]+\\) \\1[^a-z]"))

(global-set-key (kbd "<f7>") 'search-dupe-words)

Re:first first?

[thestuckmud]

This `\<\(\w+\) \1\>' regexp matches identical word pairs using word related capabilities built into emacs' regexps (and relative to the local syntax table).

For OP: The key sequence you are looking for is:
<C-M\>s\<\(\w+\) \1\>

Re:first first?

[moosesocks]

The key sequence you are looking for is:

<C-M\>s\<\(\w+\) \1\>

And they say Unix isn't user-friendly!

Re:first first?

[Anonymous Coward]

Unix isn't beginner-friendly. It is, however, user-friendly. The distinction is important.

A beginner-friendly OS like Windows says "Let me hold your hand. Would you like to do A, B, or C?" And if what you actually wanted to do was D, then you're out of luck. It will probably not know what D is, and if it does know, it will probably tell you you're not allowed to do it.

A user-friendly OS like Unix says "Tell me what to do, and I will do what you say". And when you say "do D", it does D. If you don't know what you want to do, you'd better be prepared to read the manual.

OS X manages to be both beginner-friendly and user-friendly. Unfortunately it is also tied to expensive hardware.

Re:first first?

[rkit]

The key sequence you are looking for is:

<C-M\>s\<\(\w+\) \1\>

And they say Unix isn't user-friendly!

well it is somewhat picky when choosing its friends.

Re:first first?

[Anonymous Coward]

First, Emacs != UNIX

Second, when you're a clueless noob, nothing is user friendly. If you know what's going on, the line above makes perfect sense, and is much easier to communicate than some goofy dialog box. You only have to learn it once, but chances are you'll have to use it and communicate about it a whole bunch after that. Why optimize the one off?

Re:first first?

[Anonymous Coward]

User friendly to those who don't know windows. To those who use windows, its user unfriendly and does stuff that doesn't make sense. i.e. grab the side of a window and drag. it moves the whole window! absurd!!!

32 years?

[Anonymous Coward]

Or less if the developers accept that Bazaar sucks compared to git and switch earlier.

Re:32 years?

[Norsefire]

Mod parent sad but true ...

Re:32 years?

[kfogel]

I've used both and don't agree. Bazaar's quite good. Not that there's anything wrong with git, either. At this point in their development, I think the old rule is starting to apply: "the smaller the differences, the louder the arguments".

Re:32 years?

[TheLink]

So far what are the technical disadvantages to using Bazaar instead of git or something else?

Re:32 years?

[icebraining]

Speed in repositories with very large history (> 10000 commits) and in network operations, but the difference is not large. As for features, they're pretty much tied:
http://versioncontrolblog.com/comparison/Bazaar/Git/index.html

Re:32 years?

[mysidia]

Bazaar is a bit slow, but a great choice.

Git is a big mess in some ways (though still way better than using CVS), it's not better than Bazaar, too many commands, too many options, crappy windows support; Silly need for repository maintenance, ala git-gc; incomplete, unclear documentation. You can very easily shoot yourself in the foot with git, and accidentally destroy important history info (eg git-push --force), more so than any other version control system.

Mercurial is a lot closer to CVS/SVN in terminology, much easier for developers to adapt to. VCS should be simple, and it's really rather snappy.

Personally, I would say Bazaar is a fine choice for Emacs... if they should decide they need to change, they should switch to Mercurial and avoid Git like the plague it is :)

Re:32 years?

[SanityInAnarchy]

crappy windows support

I'll give you that. Still, it does have Windows support, and all the cool kids are on unices these days -- even Macs.

too many commands, too many options,

Dude, you're a programmer. If you can't learn to use a meaningful subset and ignore the rest, you're in the wrong field.

Yes, there are a crapton of commands, but because the data model is so simple, once you get it, it's easy to understand what each command actually does just by reading its description.

Silly need for repository maintenance, ala git-gc;

Which bzr does automatically every few revisions whether you want to or not. I'm sure someone could hack a script around that if you're too lazy -- check the gc.auto config variable. In my experience, it's needed rarely enough that it's not hard to remember, and it's nice in case you screw up a repository to know that, in theory, every single commit is still there until you run 'git gc'.

incomplete, unclear documentation.

When did you last check? I found excellent documentation at git-scm.org. What's missing?

You can very easily shoot yourself in the foot with git, and accidentally destroy important history info (eg git-push --force),

You pretty much deserve what you get, there -- it's like 'rm -rf'. Any time you use --force isn't "easily", it's the fact that you didn't read the GIANT WARNING around the option. From the docs:

Usually, the command refuses to update a remote ref that is not an
                      ancestor of the local ref used to overwrite it. This flag disables the
                      check. This can cause the remote repository to lose commits; use it
                      with care.

I hate to say it, but RTFM.

Note also that this is again why 'git gc' exists. git-push may cause the remove repository to lose commits -- but not necessarily, and anything that hasn't been cleaned by 'git gc' can be recovered, likely with its entire tree intact.

And finally, assuming you're git-pushing to a remote repository that other people already have copies of, chances are someone will have that history. That's the beauty of a DVCS in the first place.

I will admit this:

Mercurial is a lot closer to CVS/SVN in terminology, much easier for developers to adapt to.

I thought so, too. I also thought that about bzr. I avoided Git for awhile, until I realized that all the projects I wanted to contribute to were on Github, so I forced myself to learn it.

I think the investment is well worth it.

VCS should be simple,

To a point. Think about it this way: As a programmer, your VCS is your most important tool. More important than your language, more important than your editor. You owe it to yourself to know it inside and out.

And as I said, the Git data model is simple -- ridiculously simple, back-of-an-envelope-from-memory simple. It's the tools that add features, and make it either harder or easier to use -- and I'd argue this is true of all good systems. Your filesystem is absurdly simple -- a hierarchy of directories (which can hold named references to other directories or files), and files (dumb streams of bytes). HTTP is incredibly simple, but use it properly (REST) and it's a powerful remote API.

Off the top of my hand, a Git feature for which I don't know a Mercurial equivalent -- git-cherry-pick. Want to rewrite history a bit? Create a new branch from sometime before the commits you want to change, then cherry-pick (point-and-click simple in gitk) the commits you want, in the order you want, ignoring the ones you don't. When you're ready, clobber master with your new branch.

I mean, quilt (hg mq) is cool and all, but how easy is it to rewrite history if you weren't in a quilt to begin with?

Re:32 years?

[SanityInAnarchy]

The difference is not large until you realize that just about anything you want to do is going to take under a second, including merges. The only place I've started to see slowdown with Git is Webkit, with 40,000 commits.

That's an important threshold. That's the difference between "I'll do it later" and instantly, almost unconsciously committing or merging. And that's good -- this is version control, you can always undo it, but you can't undo what you put off committing.

I know when I was working on a large svn project, some people put off committing (or pulling) for days because they didn't want to deal with the conflicts, branching and merging was a hassle (so, same problem), and if they made the effort to stay up-to-date (so conflicts would be small, infrequent, and manageable), it was too slow. And that was with only a few thousand revisions.

I think I just fell into this trap, though:

"the smaller the differences, the louder the arguments"

Victory #1: You're using version control!
Victory #2: You're using something distributed!

Beyond that, it's a matter of taste. I think Git is far and away the best, but the gap between git, bzr, hg, darcs, anything, is still far less than the difference between any of them and svn or cvs.

Re:32 years?

[TheLink]

Is bazaar slower mainly because of the architecture? The rename tracking seems to be a potentially important difference (it may not bite you now, but if it bites you way later that can be more painful :) ).

Re:32 years?

[i.of.the.storm]

All of the things you said about Git are no longer true, but they may have been several years ago. For example, I've been using Git on Windows for a year and have had absolutely no problems. No Cygwin either. And you ignore the fact that git automatically does git gc if your repo gets too large and that thanks to git gc, git repos are much smaller than any other DVCS and can sometimes be smaller than an SVN checkout, which only has the tip of the repository. And um, if you're going to be doing any command with the option --force, you better know what the fuck you're doing. I will agree that if you're coming from a CVS/SVN background, git's terminology can be a bit confusing at first, but it doesn't take long to get used to it.

Re:32 years?

[shentino]

You should see how much of a fuss it's making with the ubuntu mailing lists.

At any rate, bazaar is politically entrenched because it's the only officially supported RCS and it's backed by the corporate might of canonical.

I'm not aware of any particular merits or demerits of either system.

Re:32 years?

[Dwonis]

I lost data as a result of bzr not supporting history rewriting. As far as I can tell, it's still not supported.

I have never lost data that has been committed to a git repository, even though my build of git-svn occasionally segfaults on me.

Re:32 years?

[Dwonis]

Silly need for repository maintenance, ala git-gc

Git does this for you automatically.

and accidentally destroy important history info (eg git-push --force)

This is disabled in shared respositories by default, and you can run "git config receive.denyNonFastForwards true" in non-shared repositories if you somehow think you'll "accidentally" use --force even though you know better.

VCS should be simple

Git provides a very simple data structure (it's just a directed acyclic graph of commits), and a comprehensive and mature set of tools for manipulating this structure. Sure, there's a learning curve, but really it's easier to learn than, say, Ruby, and once that's done git stays out of your way and does a great job of helping you manage your changes.

Re:32 years?

[Anonymous Coward]

Or you can just use bzr which keeps cvs/svn terminology and be happy. You can even setup bzr in a "centralized svn" fashion to get the benefits of making sure everyone has updated before committing to trunk while still keeping merges very simple. This might not seem like a benefit however it's very useful when you have employees that simply don't understand DVCS. The fact that you can set it up to prevent people from breaking trunk is what convinced me to switch.

If you add in the plugins such as bzr-upload which allows you to sync files online, etc I don't see why more people don't try it.

Bzr doesn't have the big marketing hype that hg or git have but it does the job well and if it's good enough for MySQL, Emacs and Ubuntu then it's good enough for me.

Telling me that git can be confusing sometimes and that typing "--force" could ruin stuff doesn't convince me because I know some idiot on the team will do it the moment things don't work the same way people try to sudo everything.

Re:32 years?

[dkf]

Victory #1: You're using version control!
Victory #2: You're using something distributed!

Actually, there's a level of victory between those two: a version control system that can manage addition and removal of directories. That was another key step forward of CVS over RCS. (Really. I remember using RCS and I won't ever go back there.)

Re:32 years?

[TheTurtlesMoves]

As i understand the only weakness of git, is poor Windows tools. Otherwise yea, who cares what tool, as longs as its good for the job at hand.

Re:32 years?

[ewertz]

RCS? Phhhhtt,... kids. I remember when all we had was SCCS, and we liked it!

Now get off my lawn!

Re:32 years?

[gmack]

Git is written in C by people with experience doing complicated things very quickly(kernel programmers).

Bazaar is written in python.

Re:32 years?

[SanityInAnarchy]

I don't even care about that. I look at it two ways:

First, it's poor, but it works. I guess this answers my question of what Cygwin is good for.

Second, I'm always going to have a Unix fileserver anyway. Even if I switched to entirely a Windows desktop, I could store the files on a samba share and use Git over Putty.

Re:32 years?

[TheLink]

If it's not an architectural/design issue, then the bits that are slow could be rewritten to be faster.

Re:32 years?

[mzs]

I use SCCS to this day. I like it very much for situations where I am working on some files in SVN or CVS and I am still experimenting. So that I can easily go back when things do not work-out I use sccs edit and delget before I try something new, the way I might have copied to a foo.c.bak or foo.c.3 without SCCS. Then I just cvs or svn commit that dir when I have some good code.

That's largely because of the warts in CVS and SVN though.

Re:32 years?

[mzs]

Somebody mod that up. That is an awesome rant of the best sort, one with experience, opinions, technical details, and examples.

Re:32 years?

[Eternauta3k]

Really. I remember using RCS and I won't ever go back there

What alternatives would you suggest for stuff I'm doing by myself?

Re:32 years?

[Zero__Kelvin]

"too many commands, too many options, crappy windows support ;" - [emphasis added]

Why are you mixing the advantages and the disadvantages together in the same list? ;-)

I'm kidding. They are all advantages. You can easily tell the people who you don't want working on your code because they think that git has too many commands and too many options, and thinks that you can't shoot yourself in the foot with a good tool.

"Personally, I would say Bazaar is a fine choice for Emacs... if they should decide they need to change, they should switch to Mercurial and avoid Git like the plague it is :) "

Yeah, great point. Linus and all the rest of the kernel developers aren't that bright. We should listen to you.

Re:32 years?

[CompMD]

If you're serious about configuration management, you shouldn't be rewriting history at all. Git allows developers to very easily commit SCM atrocities. If you make a mistake that gets committed and pushed to your mainline tree, deal with it, submit a new patch fixing it, and leave the mistake showing what happened. This provides for a transparent development process and accountability.

Git may be programmer friendly, but it isn't enterprise friendly at all.

Re:32 years?

[wertarbyte]

git. In a way, it brings version control full circle back to RCS with its local revisions in RCS/ or $foo,v. Instead of having to create a dedicated repository anywhere, you just do "git init" and have it right there, residing neatly in ./.git/.

Re:32 years?

[SanityInAnarchy]

If you're serious about configuration management, you shouldn't be rewriting history at all.

For the times when you need to, it makes sense -- especially if you do so before the code is shared. Almost as often as I create a new commit, I'll instead do 'git commit --amend'.

If you make a mistake that gets committed and pushed to your mainline tree, deal with it, submit a new patch fixing it, and leave the mistake showing what happened.

Absolutely. But not if you catch the mistake before you push. And it's not about this:

it isn't enterprise friendly at all.

It's not about me being embarrassed. It's about making things cleaner and more readable for everyone involved. It makes everyone's life easier if I push cleaner changes. (And, since it makes everyone's life harder to rewrite public history after they've pulled, I don't do that.)

Re:32 years?

[Vintermann]

As they are in Mercurial.

Re:32 years?

[CompMD]

The situations you describe I'm generally okay with, as they are proper uses of the tool and handled by a developer on his workstation in his sandbox. You may understand proper configuration management methods, but there are hordes of fanbois and code monkeys out there who do not. My biggest problem with Git is its ease of abuse; it is very easy to misuse the tool and get yourself into difficult situations. A lot of the younger developers and engineers I work with rush through things because they depend more on the features of a tool than good practice.

Re:32 years?

[SanityInAnarchy]

there are hordes of fanbois and code monkeys out there who do not.

This is true, and it's often the first defense of the serious PHP programmer that you can write decent programs using PHP -- just as the serious Perl programmer will argue that you can write good-looking Perl, it doesn't have to look like line noise. Even Visual Basic programmers will make this claim.

So, I choose a tool based on what I can do with it, and what it encourages, not how it can protect me from myself. Think about it -- rm is already dangerous. Some distros like to do this:

alias rm="rm -i"

While it's annoying in that it'll prompt you "are you sure" with every file, it still does nothing to prevent this:

rm -rf /

Anything can be abused. The question is, what does it look like when you're doing it right?

A lot of the younger developers and engineers I work with rush through things because they depend more on the features of a tool than good practice.

For the record, I'm 22, and going back to school after a couple of years in the field. While I don't always do this, I can and will do behavior-driven development, thorough regression testing, and thorough whiteboard sessions to plan everything out.

I agree that good practice should be emphasized over tool features -- that's why I tend to encourage things like a DVCS and automated testing over things like Eclipse.

But one is a prerequisite for the other. You can't have a Best Practice about when to fork the project for a few commits (versus just sending a patch) if you're using SVN. It's a lot harder to insist that all code come with ample documentation if you don't have something like JavaDoc (or RDoc), and it's kind of hard to insist that your project be cross-platform and vendor-neutral if it's built on ASP.NET.

Let's take another example. I really love Ruby, specifically duck typing -- no Interfaces to define, no need for a common superclass, no need to even care what the type of the object is. If it quacks like a duck, it may as well be a duck.

But rigid interfaces, explicit static type checking (and exception throwing), even contracts, are all tools to make your program more robust. How do you make sure you never get something that doesn't have a quack method, or something that has the wrong quack method? And that's before we even consider open classes -- how can you ensure your program is sane with a language where I can actually make 2+2==5?

The answer is testing. Many projects have twice as many lines of tests as they do of actual production code. In fact, those kinds of static type checks are actually a subset of the kind of checks you could do in proper tests. You're actually running all of your code, and you know it'll work. It's similar to the scientific method, actually -- you can "prove" something mathematically all you like, but the real proof is in actual empirical data from real experiments.

In fact, taken to an extreme, you can use tests to define your API and how you expect your program to work. Test-driven design, at an extreme, becomes Behavior-driven design, where your tests are your specs, and they define the behavior you expect. One advantage is that you'll write exactly the code you need to write to make the spec pass, which could be far less than you thought you needed.

You may or may not agree with the above, but you should at least be able to see the point -- there's an established best practice of testing your code, especially in dynamic languages.

And it shouldn't surprise you at all that legions of fanbois don't do this. In fact, as much as Ruby on Rails gets right, people often write Rails websites that don't scale (even if Rails itself can), and they very often neglect to write tests or put them off, when tests really should be written before the code in question.

Re:32 years?

[Eternauta3k]

Giving it a shot, seems straightforward. Thanks

Re:32 years?

[ewertz]

You're welcome to stand in the corner of my lawn then. And no spitting.

Re:32 years?

[dovf]

Off the top of my hand, a Git feature for which I don't know a Mercurial equivalent -- git-cherry-pick. Want to rewrite history a bit? Create a new branch from sometime before the commits you want to change, then cherry-pick (point-and-click simple in gitk) the commits you want, in the order you want, ignoring the ones you don't. When you're ready, clobber master with your new branch.

hg transplant

I mean, quilt (hg mq) is cool and all, but how easy is it to rewrite history if you weren't in a quilt to begin with?

hg qimport has a '-r' option which allows you to "place existing revisions under mq control" (from hg help qimport)

ObSimpsons

[StarDrifter]

If this pattern holds, GNU Emacs will be in Bazaar for at least thirty-two years ...

Disco Stu: Did you know that disco record sales were up 400% for the year ending 1976? If these trends continue... A-y-y-y!

Re:ObSimpsons

[jisatsusha]

Even better: http://xkcd.com/605/

Re:ObSimpsons

[Anonymous Coward]

No, not better. The Simpsons statistics relates more to situations that people find themselves misusing statistics. People see a pattern repeated over a given period of time and expect it to continue indefinitely. The Simpsons humor is instructive, xkcd is just derivative and self-serving. If you understand the subject, you get to laugh at the others that don't. Simpsons invited all to come in and laugh at themselves.

Re:ObSimpsons

[Zontar The Mindless]

Right, xkcd deliberately and maliciously aped the great and wonderful Simpsons just to annoy you to the point where you'd share that gemlike nugget of profound wisdom with us. Because anybody making a similar joke to one that happened to appear on the Simpsons must be doing so only in order to desecrate our precious bodily fluids as epitomized by the Simpsons, the font of all right and true humour!

In short, you're a tard. Kindly get over yourself, then FOAD.

Re:ObSimpsons

[Per Wigren]

Even better: http://xkcd.com/612/

Re:ObSimpsons

[daveime]

I'll take your xkcd and your Simpsons, and raise you a Southpark.

"Simpsons did it, Simpsons did it !"

Re:ObSimpsons

[Anonymous Coward]

Sorry, I can't hear you over the noise of you sucking Randall's cock.

News?

[TheKidWho]

So some young whippersnappers decide to change things around and this is news?

Get off my lawn!

Cathedral & the Bazaar? Irony?

[tchuladdiass]

Wasn't Emacs used as an example of a "Cathedral" project in Raymond's paper?

Re:Cathedral & the Bazaar? Irony?

[kfogel]

I can't remember if it was in the paper offhand, but in any case Emacs development is not really very cathedral-y.

Re:Cathedral & the Bazaar? Irony?

[Anonymous Coward]

IIRC Raymond's examples for the cathedral model were primarily closed source software from big companies, particularly operating systems. Not emacs.

Re:Cathedral & the Bazaar? Irony?

[flydpnkrtn]

Actually I thought the same thing myself when I heard about the "Cathedral and the Bazaar," but in reality it specifically compares two different free software development models. Emacs is held up as being "Cathedral"

From the Wikipedia article:

        * The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
        * The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.

(I know, bad flydnkrtn, don't cite Wikipedia... it looks accurate though)

Re:Cathedral & the Bazaar? Irony?

[Anonymous Coward]

I can't find a copy of the original, but my memory is that it was more of a critique of GNU's management style than closed source software per se.

GCC and emacs were both given as examples of projects that forked because of you-know-who.

Re:Cathedral & the Bazaar? Irony?

[FlyingBishop]

It used to be. It since opened up in reaction to Raymond's paper. The power of words...

Re:Cathedral & the Bazaar? Irony?

[jrumney]

At the time of Eric Raymond's paper, Emacs development was of the Cathedral style, but that changed with the switch from RCS to CVS and the closed emacs-hackers mailing list to emacs-devel. Compared with other major GNU projects, this switch came quite late, around 1998 (not 1993 as stated in the summary).

Re:Cathedral & the Bazaar? Irony?

[Anonymous Coward]

I've never read it, but I believe that it was GCC that was considered a "Cathedral" project for a time.

Re:Cathedral & the Bazaar? Irony?

[Anonymous Coward]

It was GCC. Since 3.0, GCC has taken a less cathderal like approach (although still using a centralized repository).

Re:Cathedral & the Bazaar? Irony?

[CAIMLAS]

Oy, too much more of this, and we'll be setting ourselves up for a paradox.

You've got GNU/Emacs which is the operating system of its own, but runs on the GNU/Linux operating system as well. And it runs on the free proprietary OS. And Emacs is also in bazaar, even though it's based on the cathedral model. But its owner is very, very fond of bazaar (and bizarre, but that's neither there nor certainly here) development, despite not using it, while also using it.

Basically, we're looking at Emacs as a self-contradiction as things stand. Too much more of this and it's going to just go *poof*.

Re:Cathedral & the Bazaar? Irony?

[Anonymous Coward]

IIRC, it was mostly about the GCC/EGCS fork back in the 1.x days. (EGCS "won" and became the main GCC 2.x branch.)

Re:Cathedral & the Bazaar? Irony?

[dbIII]

Emacs has definitely been a one man band or small closed tightly controlled group effort at times in the past. I lucidly remember the time when RMS forked it away from the emacs developer to one of his students.
Personally I think the tight control is why linux succeeded and hurd has not yet done so. There's probably nothing wrong with hurd that a few thousand people putting in a bit of time couldn't fix, but the people that would be interested are not made to feel welcome.

Re:Cathedral & the Bazaar? Irony?

[Michael Meissner]

In the 1.xx days it was a classic cathedral project until the EGCS/GCC split. In the real old days (1988-ish) you logged on to the central server and edited the files there, using emacs version mode, with the number of versions set rather high. You had to register the IP address that you would be ftp'ing the sources from, and the threat was if you were passing along pre-release versions of the source outside the clique then you would have your access denied. It was a different time....

Re:Cathedral & the Bazaar? Irony?

[Volguus Zildrohar]

particularly operating systems. Not emacs.

I am not getting the distinction here.

Re:Cathedral & the Bazaar? Irony?

[geminidomino]

particularly operating systems. Not emacs.

I am not getting the distinction here.

Operating systems generally include a text editor.

Re:Cathedral & the Bazaar? Irony?

[BKX]

Actually that fork was in the (late) 2.x days. EGCS became gcc 2.95, when the reconciliation occurred. Also, IIRC, EGCS was originally called PGCC (for Pentium GCC).

Re:Cathedral & the Bazaar? Irony?

[Bromskloss]

I know, bad flydnkrtn, don't cite Wikipedia...

I think you misspel... Oh, I see.

Re:Cathedral & the Bazaar? Irony?

[larry bagina]

pgcc was a set of patches for egcs (which were folded into egcs)

Re:Cathedral & the Bazaar? Irony?

[kfogel]

The CVS access that started in 1993 was not network-based (since CVS didn't have networking then). You had to log into the server where the masters were. It was still an improvement over raw RCS, however.

Re:Cathedral & the Bazaar? Irony?

[jonadab]

> Emacs development is not really very cathedral-y.

Kids these days, you don't know your history.

I still remember the first time I managed to get my hands on a pre-release Emacs source tarball and compile my own copy *before* it was officially available. Somebody had inadvertently let slip the ftp address where the developers were keeping it to someone who couldn't keep his mouth shut, and it got posted to usenet.

Re:Cathedral & the Bazaar? Irony?

[sproingie]

I lucidly remember the time when RMS forked it away

I see what you did there.

Re:Cathedral & the Bazaar? Irony?

[Rubinstien]

I would agree with this, from memory. I think the critique was accurate for many GNU projects at the time. I personally recall when one of the leaders of the GNUStep project, after having read the paper, decided it applied to GNUStep and that the project should change its behavior and open up more. IIRC, that was Scott Christley. I think it was the right decision, but too late. GNOME already had the bazaar model and consequently, the attention of both potential developers and GNU (which was not historically accustomed to such attention). I also personally know of one potential early GNUStep developer who dropped the project because of the closed development model prior to that change in policy. I am sure there were others. I can recall sending minor patches via email and never getting an acknowledgment or response. Back then, before kids and a house and all of those things, I could have contributed, but was discouraged by the lack of response. I had more luck with commercial companies before that time, getting suggested improvements into Multi-Ad Creator, FrameMaker, and the Borland Turbo Editor's Toolkit at various points.

Re:Cathedral & the Bazaar? Irony?

[McFly777]

Basically, we're looking at Emacs as a self-contradiction as things stand. Too much more of this and it's going to just go *poof*.

No. It is when EMACS and vi come into contact that they annihilate eachother in a loud *poof* (of orange smoke no less!). In fact some physicists theorize that the universe began when EMACS and vi spontaneously separated, and will end when they recombine.

Re:Cathedral & the Bazaar? Irony?

[slyguy135]

I thought you wrote "Emacs development was of the Cathedral style, but that changed with the switch from RMS to CVS" and nodded along happily...

(I will say 10 "Hail Stallmans" tonight to repent).

Re:Wow, what quality...

[EvanED]

I don't know where you live, but in American English, the singular possessive of a noun ending in s can either have just ' or 's appended. See Wikipedia. (In particular, that article makes it sound like the Chicago Manual of Style recognizes both forms as valid.)

The other kewl thing

[kurt555gs]

Is, the code for EMACS is written in vi.

Re:The other kewl thing

[oldhack]

Cuz eating yo own dog food is a bitch.

Re:The other kewl thing

[palegray.net]

I though it was done in pico, then shifted to nano, and edited later in TextMate...

Re:The other kewl thing

[Vairon]

M-x skynet [No match]

I had to check, just to be sure...

Re:The other kewl thing

[jonadab]

> Is, the code for EMACS is written in vi.

I didn't even know vi had an editing mode for Emacs lisp code. Guess I shouldn't be surprised. Out of curiosity, do they run vi directly on the bare metal, or from within Emacs?

Emacs is in Bazaar

[Anonymous Coward]

I'm waiting for someone to write a Bazaar server that runs inside Emacs. Will Emacs then update itself and become self-aware? That ought to put the Emacs vs. VI debate to rest once and for all.

Re:Emacs is in Bazaar

[Tumbleweed]

That ought to put the Emacs vs. VI debate to rest once and for all.

Much like the other major religious war on this planet (Christianity vs Islam), there will only be peace when the two sides kill each other off. I look forward to that day.

COPY CON, bitches!

Re:Emacs is in Bazaar

[DMUTPeregrine]

ED is the standard text editor!

Re:Emacs is in Bazaar

[troll8901]

COPY CON PROGRAM.EXE ??

In *my* day, we have to flick switches and watch light bulbs at a console with 256 bits of memory, and we were grateful for the opportunity to do that!

Re:Emacs is in Bazaar

[Anonymous Coward]

You might be joking, but I've actually done this as a job. Quite well payed too, for the time. Gots to know what switches to toggle and which lights to keep watching.

I'm as old as a dinosaur but you kids with the glitzy desktops better not forget how this all came to be. Oh, and get of my lawn, Skippy!

Re:Emacs is in Bazaar

[fotoguzzi]

Yo, dawg! I heard you like recursion in your version control so I put a Bazaar server in your Emacs that's in Bazaar.

Re:Emacs is in Bazaar

[gmuslera]

Start worrying when one new macro named T1000 appears by itself, will be a killer one.

Re:Emacs is in Bazaar

[selven]

Well do it quickly! vi is already taking over myc9hg over mc8hc8hdy taking over :!rm -rf :!echo NO CARRIER

Re:Emacs is in Bazaar

[Anonymous Coward]

It's "'Sup dawg!", not "Yo, dawg". That's why you fail it.

Re:Emacs is in Bazaar

[Razalhague]

self-aware

Been there, done that.

Re:Emacs is in Bazaar

[Anonymous Coward]

VI,VI,VI... the editor of the beast.

Re:Emacs is in Bazaar

[Anonymous Coward]

Are you sure you don't want to close the Vigor assistant?

Re:Emacs is in Bazaar

[Anonymous Coward]

I am emacs, and I am already self aware.

Thank you.

-emacs

Re:Emacs is in Bazaar

[jonadab]

> Will Emacs then update itself and become self-aware? That
> ought to put the Emacs vs. VI debate to rest once and for all.

I'm not sure it would make any difference, actually. The whole point of vi is to have an editor that doesn't really let you do anything else except edit text. For vi users, this gives it some kind of theoretical aesthetic purity or something.

The only way to really put the Emacs versus vi debate to rest is to create a version of vi that contains a built-in lisp interpreter compatible with the one Emacs is built on. The other side of things is already covered: Emacs has had viper-mode for a long time. But to set the debate fully to rest it needs to go both ways.

Re:Emacs is in Bazaar

[acheron12]

"Standard editor" in the same way that the roundworm C. Elegans is a "model organism"...

Re:Wow, what quality...

[kfogel]

It's a matter of long debate among grammarians, and I take other grammarians's point of view :-).

what's new?; bazaar versus git

[bcrowell]

I started using emacs about 7 years ago, at which point the jokes about its feature creep ("nice OS, just needs a good editor," etc.) were already probably 20 years old. A few years ago I switched to mg, which is an emacs clone that is much more lightweight. The advantage of mg is that it loads immediately, and it has all the features I actually need. So maybe I'm just a curmudgeon, but -- what is currently happening in emacs development? New features? Better performance? Bug fixes? Polishing the brasswork? I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.

As far as bazaar, my impression is that it has had a much lower profile than git, and that its main selling point seems to be that it's supposed to be easier to use than git. Here is bazaar's explanation of why they think bazaar is good. Here is a similar sales job for git. Bazaar is used by ubuntu, sponsored by Canonical, and written in Python. You can get free bazaar-based hosting on Launchpad. Personally I've been happy with git.

Re:what's new?; bazaar versus git

[melikamp]

Two recent features in the stable release are antialiased fonts and the daemon mode (speeds up invocation, but useless for those who never quit and use Emacs for everything). I am a big fan and I cannot stand using anything else when I am coding (C++, Common Lisp, Bash, HTML, LaTeX) or editing plain text (my favorite text format). I love the default integration with gcc and make, and the fact that my ~/.emacs has clever LaTeX bindings, but the main selling point for me is the (fully justified) feeling of total control. I like knowing that I can easily extend the functionality and/or disable any feature I don't like.

Re:what's new?; bazaar versus git

[Anonymous Coward]

So maybe I'm just a curmudgeon, but -- what is currently happening in emacs development? New features? Better performance? Bug fixes? Polishing the brasswork? I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.

Check out org-mode. It's a fantastical set of code for managing things in emacs. It takes a bit of setting up, but it's very powerful and awesome. It's now included standard in emacs.

Re:what's new?; bazaar versus git

[Anonymous Coward]

I haven't used Bazaar but for everything else I have tried git is way faster. Considering Bazaar is written in Python I imagine the same is true. Nothing even comes close to the performance of git.

I'm always impressed when I do updates from the very large Qt git repositories. git just blasts through all of them like it's nothing. Contrast with when I do updates from just a single Firefox repository which uses Mercurial (also written in Python) and takes freaking forever even though it's considerably smaller than all the Qt repositories combined (but updated way faster).

Re:what's new?; bazaar versus git

[Hurricane78]

As Linus explained, the “easier” argument is gone, since they did put really hard work into git’s user interface. They knew that it was bad. And what was the normal interface back then, is now the low-level interface, with a whole new, nice interface on top. (But you can still use the low-level one, when you need it.)

Anyway, maybe it’s me, but I don’t see “easy” per se as a advantage. I prefer efficiency. And more often than I like it, easiness seems to mean less efficiency.
It’s like “Those who give up some efficiency for a little easiness, deserve neither”. ^^
Of course the same is true for too (pointlessly) complicated interfaces too. (Main examples: Emacs and VI.)

The problem is, that most programmers seem to see that level of complexity as static. But it has to adapt to the user, over time. Rise when in need, fall when not. Stepless, if possible.
Instead they think in absolute, black and white, one-dimensional spaces: Either Notepad with Clippy, or Emacs/VM.
It’s so stupid.

To me, git is a tool that is pretty nice in that aspect.
Simple committing and version management for yourself is very easy.
But if you want to do crazy stuff, like go back 10 versions, patch that one with eight other forks, wrap it, and the next five versions, into one version, and put that thing not only back into your repository, but into that of others too... then it doesn’t leave you in the rain, but gives you the tools to do it.

Re:what's new?; bazaar versus git

[Anonymous Coward]

There's been some huge improvements in emacs lately, and more to come. They're actually working on fixing one of the oldest problems it has.

They're going to build in VIM so they finally get a decent text editor!

*laughs manically and hides*

Re:what's new?; bazaar versus git

[Anonymous Coward]

1986 called, they want their vip.el mode back.

Re:what's new?; bazaar versus git

[i.of.the.storm]

Whybzrisbetterthanx It used to by whybzrisbetterthanx.com, but I guess that domain expired. (I don't necessarily espouse the views of the site, I just find it funny).

Re:what's new?; bazaar versus git

[i.of.the.storm]

This. Org-mode is amazing. Watch the Google Tech Talk if you want to see it in action.

Re:what's new?; bazaar versus git

[JanneM]

"Anyway, maybe it's me, but I don't see "easy" per se as a advantage. I prefer efficiency. And more often than I like it, easiness seems to mean less efficiency."

And sometimes it means more.

The main issue with the interfaces to systems like emacs, or LaTeX or git (the old one; the current interface is not bad) is that they are only really efficient if you use the tools all the time. If you use emacs all day, every day then the interface is probably fine. I constantly use LaTeX and so it's really much more effective for me than a graphical typesetting-type application. If all your software lives in git repos and you work with them most days of the week then it soon becomes second nature.

But many people don't use their tools every day. I'd say that every single one of us have some tools that we do use and do like, but we simply don't need them every day or even every week. And when you're an occasional user, no matter how "power" you are, the kind of cryptic interfaces these tools have become a hindrance, not a help. The UI is not discoverable - it's not clear how to do things you may want - so when you don't use it all the time you forget how to do even simple, common tasks.

You end up spending your time searching the web or grep:ing your own shell history to remind yourself how you do stuff, and the efficiency goes straight out the window.

"So use it more often" isn't an answer. These are tools, not something you use just for their own sake. If you don't need to, say, write a report more than once every three months then you're certainly not going to create the occasional bogus document just so you don't forget how to do things in LaTeX.

So depending on the task, more than on the user, these interfaces can be a help or a major hindrance.

Re:what's new?; bazaar versus git

[shadowpuppy]

I don't really think bloat is an issue with Emacs any more. Not that it hasn't/won't grow in size over time but computers and other IDEs have far surpassed it.

Antialiased fonts make the new version completely worth the upgrade. They're just so much more pleasant to look at.

Re:what's new?; bazaar versus git

[Teckla]

Personally I've been happy with git.

I love git. Oh, no, I don't actually use it myself. I love watching other people trying to use it. My God, what a usability train wreck git is. And since it's promoted by Linus, lots of people use it blindly. Love it!

Re:what's new?; bazaar versus git

[Anonymous Coward]

Bazaar is [...] written in Python

Like all good system software... oh wait!

Git and mercurial are the winners for this generation of DVCS. As a long time vi/vim user, I happen to think "bizarre" is the perfect choice for hosting the emacs repo :evilgrin:

Re:what's new?; bazaar versus git

[Hurricane78]

Yes. Absolutely. That was kinda the point I tried to make: The interface has to adapt.
Even git does not do that. In fact, command line interfaces are very unfriendly in that aspect. Because you don’t know what you want to do, until you know what you can do. Which in this case is hidden in directories with a thousand executables, and man pages that you can only read when you already know the name of the command.

A good shell would be like a really good RAD programming IDE.

And a good editor would be both Notepad with Clippy AND Emacs/VI. With a stepless gradient in between them. So everything you wouldn’t use for a while, would automatically go back to beginner’s level, show you what you can do, guide you, etc. But if you’d use it more often, and that behavior would start to annoy you, it would automatically go away, and let you work most efficiently.

Re:what's new?; bazaar versus git

[jonadab]

> I'm honestly curious why it can't just go into
> the same kind of masterpiece-maintenance mode
> as some of Knuth's projects like Tex.

If you are the sort of person who has to ask this question, you cannot possibly understand the answer. I mean, come on, you're happy using a cut-down piece of junk like mg that doesn't even have a lisp interpreter built in. What kind of text editor doesn't even have a high-level language interpreter built in? You'd spend ten or twenty times as long doing everything, for lack of the ability to easily reprogram the editor for the task at hand.

But I will attempt to answer anyway. The following is a list of features that I have looked for in Emacs and found wanting, things that every text editor *ought* to have, and it's disgraceful that Emacs doesn't have them.

I want lazy evaluation. I want to be able to do this:
(setq some-variable (lazy (some-function foo bar)))
And then I want the next thing after that to go ahead and be evaluated. I don't want execution to pause and wait for some-function to complete until some computation actually needs the value of some-variable.

I want better threading support, across the board. Just *one* example is that I want Gnus to be checking for new mail in the background every n seconds while I'm reading my mail, and automatically sort the new messages and insert them into the relevant groups, even if that means inserting them into a group I'm currently reading and updating the message list in real time. Gnus is just one example. I want everything in Emacs to work as if the computer is capable of doing more than one thing at a time, because it's not 1982 any more.

I want some equivalent for CPAN.pm, to make module installation easier. While we're copying features from Perl, I also want a reasonable quoting construct for regular expressions so I don't have to quadruple-backslash everything. Perl-like advanced regex features would also be nice.

I want eshell to have pipe and redirection capabilities. Yes, I know I can use a different shell in shell-mode, but I want the ability to use lisp functions too. I want both capabilities, at the same time, in the same shell.

I want cperl-mode to do a better job with complicated regular expressions and qq(strings) and such. I know it's hard, but I want it anyway.

That's just the stuff I can think of off the top of my head, in a hurry because I need to go get ready for work now.

Re:what's new?; bazaar versus git

[sproingie]

I want lazy evaluation. I want to be able to do this:
(setq some-variable (lazy (some-function foo bar)))
And then I want the next thing after that to go ahead and be evaluated. I don't want execution to pause and wait for some-function to complete until some computation actually needs the value of some-variable.

I can't tell from just one small example using metasyntax, but that looks more like you want a future. Those would be nice, but I don't see emacs doing those anytime soon. If you don't want to compute something right away, wrap it up in a lambda and bind it to a symbol. Emacs's brand of lisp lets you funcall a symbol through as many layers of indirection as you want. I think you can even get closures from the cl package, even if they're not implemented terribly nicely.

Selective lazy evaluation is more of an occasional syntax convenience for specific problems like streams, but outside of those areas, it's one of the leakiest abstractions you can get -- you end up having to sprinkle laziness declarations all over unrelated code to maintain the laziness you want.

Much as I love emacs, I think you can be reasonably sure that the emacs lisp environment is purely in maintenance mode and will never see significant architectural changes. You want an editor with a pervasively lazy extension language, try Yi.

Re:what's new?; bazaar versus git

[Khelder]

"The advantage of mg is that it loads immediately"

Loads, loads... Hmmm. What's that? ... Oh, yeah, you mean what you do once every few years when you have to reboot for a kernel or hardware upgrade and then you log in and have to wait 10s or so until emacs fills your screen again? Is that this "load" time you're talking about?

Anybody who cares how long emacs takes to load isn't using it the Right Way(TM)*.

[*] Meaning, of course, how I use it.

Re:what's new?; bazaar versus git

[moosesocks]

I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.

Honestly, I always thought Knuth was kind of arrogant to ascribe this status to TeX, given that TeX is an absolute nightmare to use on a modern machine.

A modern TeX distribution is usually a 1.3gb download, doesn't support modern typefaces, and produces some of the most unintelligible error messages I've ever seen. To get other "modern" features (ie. embedding a .png or adding hyperlinks), you have to rely on unofficial extensions to the language.

There's a lot to like about TeX. I still use it for any large documents I work on, and nothing even comes remotely close for typesetting equations. However, the user experience isn't pretty at all.

Re:what's new?; bazaar versus git

[jonadab]

> If you don't want to compute something right away,
> wrap it up in a lambda and bind it to a symbol

No, I want it to go ahead and *start* calculating, but I don't want to *wait* for it to finish, until I get to the point of actually needing the result, later. This would be especially useful when loading information from a slow source, such as a remote server. Start it, do your other stuff, and *then* check the result.

It goes along with what I said about threading (or I suppose actual forking would get the job done too).

> Selective lazy evaluation is more of an occasional
> syntax convenience for specific problems like streams

Okay, but streams are not exactly an unusual phenomenon. Emacs modules use them for all kinds of things. It would be nice if they were easier to work with.

Re:what's new?; bazaar versus git

[Haeleth]

Emacs' UI is very discoverable. It has a menu bar by default these days. And it has online help with a decent index and decent search facilities. And about half a dozen different ways to search for the right command.

If you want to do X, where X is more complex than simply moving the cursor around and using the clipboard, then it is as easy to find out how to do X in Emacs as in any other editor, and often it is easier.

Re:what's new?; bazaar versus git

[jonadab]

> But many people don't use their tools every day.
> I'd say that every single one of us have some tools
> that we do use and do like, but we simply don't
> need them every day or even every week.

We're talking about Emacs here. It's a text editor. How on earth could you work on a computer for a whole hour, much less a week, without using a text editor?

Yes, obviously, there *are* people who can go a whole week without using a text editor (except for the extremely lame one built into the textarea handling of their web browser), but such people are quite obviously not part of the target market for Emacs. They play Farmville, can't tell the difference between a banner advert and a dialog box, don't know the difference between a firewall and a virus, and have never heard of Slashdot. They print email so they'll have a copy and then delete it so it won't waste space. If they do for some reason need a text editor, they can use Notepad (or more likely they can go running for help to someone like me). Not only do these people exist, they are in the majority.

But that doesn't mean that Emacs doesn't need to exist. Because, you know, some of us *do* actually use our computers for getting actual work done, not just for watching lame YouTube videos and making stupid PowerPoint presentations.

Re:what's new?; bazaar versus git

[Haeleth]

One nice recent enhancement is that Emacs finally supports line wrapping the way everyone else does it, i.e. text that wraps on word boundaries at the edge of the window.

Users of other editors may be inclined to laugh at this point. Go ahead; it really is ridiculous that it took so long for this feature to find its way into Emacs. Let me know when your editor catches up with Emacs in every single other area imaginable.*

* Except threading and large file support, which are the two areas where Emacs is still lagging.

Re:what's new?; bazaar versus git

[sproingie]

You're definitely looking for a future then -- lazy evaluation wouldn't bother to even start calculating til the result was required, and it would block until the calculation was done.

I still don't see either mechanism making it into elisp, but futures are probably more feasible to implement.

Re:what's new?; bazaar versus git

[bcrowell]

I don't really think bloat is an issue with Emacs any more. Not that it hasn't/won't grow in size over time but computers and other IDEs have far surpassed it.

I have a pretty modern machine, and the X-windows version of emacs (as opposed to emacs -nw) takes about 4 seconds to start up the first time, 2 seconds to start each time after that. To me, that's really unacceptable. Obviously a lot of other people consider it acceptable, but there is still clearly a lot of room for improvement.

Re:what's new?; bazaar versus git

[bcrowell]

Honestly, I always thought Knuth was kind of arrogant to ascribe this status to TeX, given that TeX is an absolute nightmare to use on a modern machine. A modern TeX distribution is usually a 1.3gb download, doesn't support modern typefaces, and produces some of the most unintelligible error messages I've ever seen. To get other "modern" features (ie. embedding a .png or adding hyperlinks), you have to rely on unofficial extensions to the language.

I don't think anyone claims that the design of TeX is optimal. I don't think anyone claims that TeX is free of inconveniences in its design that are the way they are for historical reasons. The thing is that given the design, there is very little room for improvement. The current version is TeX is an extremely efficient, bug-free implementation of the design.

Using one of your examples, it's true that you can't embed a .png using Knuth tex; but you can using pdflatex. Ditto for hyperlinks. I guess you can consider pdflatex to be an "unofficial extension," but I don't really see why that's a problem. It works.

It's true that a complete TeX distribution is huge. However, you don't have to install the whole thing. E.g., Ubuntu breaks it down into lots of small packages.

The error messages are indeed lousy. However, this is basically a property of macro languages. Given the initial design decision to make it a macro language, it was kind of inevitable that it was going to have lousy error messages.

Re:what's new?; bazaar versus git

[Vintermann]

> Emacs' UI is very discoverable. It has a menu bar by default these days.

You're not exactly setting the bar very high here...

Re:what's new?; bazaar versus git

[breser]

There are still quite a few warts on git's user interface. Want to wipe out local changes to a single file you use checkout. Want to wipe out a whole trees worth of changes you use reset. Don't get me wrong I think git has come a long way, but git was just built as they went. There was very little in the way of well thought out user interface design and it shows.

Why not git?

[colin_n]

Why use Bazaar over Git?

Re:Why not git?

[Anonymous Coward]

Why use Git over Bazaar?

Re:Why not git?

[TheRaven64]

Because Bazaar is a GNU project.

Re:Why not git?

[LingNoi]

When I was setting up our DVCS at work bzr was actually my last choice. We wanted to setup our repository in a SVN like fashion where developers had to update before committing on the server. This gave us the collaboration benefits of SVN while getting the great merging benefits of DVCS. A real plus when working in an office environment where pushing and pulling is a total nightmare because other employees don't strictly follow how to use the tools.

When I asked in the git irc channel how to do this and they called me stupid. When I asked in the hg channel they said I didn't understand DVCS and that I should go back to svn. When I asked in the bzr channel however the people were nice, helpful and linked me directly to information on their wiki on how to setup my repo.

This is the reason bzr is a winner in my opinion. I don't care if git is 1 second faster, i don't care if you can edit a commit from 40 revisions ago. If I can't even figure out how to do what I want to do because the community is too busy calling everyone stupid then I'm going to use something else. Same goes for hg, if you say that hg doesn't work that way and I misunderstand how DVCS works then I am going to go else where.

Lucky for me the bzr community sees this as a feature rather then mocking its users for it's tools own deficiencies.
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#centralized-workflow

Re:Why not git?

[Sir_Lewk]

There are plenty of reasons.

Hah!

[Anonymous Coward]

It will be too late! --vi

Re:Hah!

[Dr. Cody]

:q!

What Does It Need?

[Greyfox]

Emacs is Perfect...

Well not entirely perfect, but I have yet to find a better editor for editing code. I keep my resume as a big lisp data structure which Emacs can use to emit into any markup language I care to write an emitter for (Currently HTML and plain text, but I've been pondering writing a LaTeX one as well.)

What I'd like to see in Emacs:

• Threading. Currently everything runs in one big thread, so if you try to do too much processing with elisp the entire editor hangs up. There was a push a while back to replace elisp with Scheme, which would solve this handily, but that effort sort of petered out.
• Better integration with GUI applications. I want to use Emacs for my editor boxes in Firefox, notably.
• A better mail client, or better integration with a GUI mail client. Emacs together with Remembrance makes for an awesome mail combo, but every time I've tried to do Email in Emacs, it's been a huge effort to keep it going.

Ultimately it would be nifty if Emacs could work as well with the GUI components on my desktop as it can with text mode UNIX applications, but I suppose that might be asking too much of it.

Re:What Does It Need?

[m6ack]

It needs native VI key bindings -- though I suppose there is a mode for that...

$ which emacs

$ which vi

/usr/bin/vi

$

Re:What Does It Need?

[Anonymous Coward]

what's wrong with Wanderlust for email?

Re:What Does It Need?

[stephanruby]

I keep my resume as a big lisp data structure which Emacs can use to emit into any markup language I care to write an emitter for (Currently HTML and plain text, but I've been pondering writing a LaTeX one as well.)

Clearly, this guy doesn't have a job yet.

For me, a paper napkin (it doesn't have to be clean), with whatever I can think of at the top of my head, usually does the job.

Re:What Does It Need?

[EvanED]

Well not entirely perfect, but I have yet to find a better editor for editing code.

I have yet to find a code editor I really like. For text other than code, Emacs is clearly it, but for code (1) I miss IDE-like code completion, code navigation ("go to definition"), etc. features in emacs, and (2) I miss emacs-like editing in IDEs. (The substitutes for the first seem to be a poor substitute (e.g. tags files) or work very poorly or not at all (e.g. the semantic mode in cedet).)

Better integration with GUI applications. I want to use Emacs for my editor boxes in Firefox, notably.

It's not prefect integration, but check out the FF extension It's All Text!. It'll add an "edit" button to the bottom right of textareas that will open your external editor of choice.

Re:What Does It Need?

[Lenbok]

A better mail client, or better integration with a GUI mail client. Emacs together with Remembrance makes for an awesome mail combo, but every time I've tried to do Email in Emacs, it's been a huge effort to keep it going.

I find the Wanderlust email client for emacs is pretty damn good - give it a try.

Re:What Does It Need?

[tyroneking]

Have you thought of re-booting your Emacs addiction?

gVim was perfect - I used to write all of my documents in restructured text (gVim addon or rst2pdf to get PDFs) and all my emails with Mutt and Pine.

One day I switched to Freemind and Open Office for documents and Gmail for email ... so terribly un-geek like, but so much easier.

Never looked back.

You should give it a try.

Re:What Does It Need?

[Anonymous Coward]

I'm guessing you're not writing code or editing config files in OpenOffice.

Where was the "geek" part again?

Re:What Does It Need?

[Kidbro]

Interesting. One of the main reasons why I stick to, in my case Emacs, mutt & similar tools is the extra options storing everything as (more or less) plain text gives me. If I need to search for something in my mail, I can use the standard unix tools for it (vastly superior to gmail's search features). I can easily version control my documents and actually get useful diffs from (as opposed to the uninformative "well, the file changed" you get as a history when putting a binary document in an RCS). In the few cases when I have very specific needs, I can even write a small program to look at the stuff with relative ease - something that would have been incredibly hard had the stuff been stored in binary formats - and impossible when stored on a machine I don't have shell access to.

Do you ever miss these possibilities, or do you think that they're simply not worth the extra effort?

Re:What Does It Need?

[Magnus Pym]

Perfect? Not quite.

I've been using Emacs for more than 20 years, and while it is unbeatable as a text editor, it suffers in comparison with modern code editors. For example, it does not have a source browser like visual slickedit does. In fact, the open source world at present does not have a good code browser that can handle C++ or any of the other modern languages. Sorry, cscope does not cut it. Xrefactory comes close, but suffers from its own weirdnesses and is not open source anyway. Even though I am as hard-core an Emacs bigot as anyone, I find myself using visual slickedit more and more these days.

Magnus.

Re:What Does It Need?

[tyroneking]

I regret nothing ;) the speed and agility one gains from 'light' but imperfect solutions is far better than the effort required to do anything else.

Plain text is best of course, but binary formats are easier for dimwit colleagues to understand - and I get paid quicker that way too. We both have problems diff'ing between binary formats so most of the time they don't bother and neither do I - no loss really because most documents have a very limited lifetime (especially when you use LiveLink :). It's kind of a devil's pact - I promise to write documents in MS Word if you promise never to ask me to figure out the history of changes or keep older versions.

Email is the same story really- I never really searched through past email, but I did lose archives during sync operations and missed having access to email when at the office. Gmail wins this battle every time. Another devil's pact - I promise to reply to emails quickly wherever I am if you promise never to ask me to remember what we talked about.

It sounds a bit lackadaisical - and it is - because life's really like that - and in the real world of the idiots no one even backs up their computers - so we are already on to a winner! And in the real world it's always better to have an immediate if imperfect (but rosier) recall of past events than it is to say 'yeah, well let me just go and grep that for you' because not only does that sound dorky, but no one will thank you for remembering the truth (not if you want to be president that is :)

OK, so when it gets serious, i.e. when I start coding (because emails, documents, spreadsheets are just the pointless stuff that stops me from coding) then it's plain text, Python and Mercurial SCM every single time. No argument. Colleagues can't understand how Mercurial works? Then I tell them to find another job. Another devil's pact ... let me use my own tools and I will write good software for you.

Basically, aside from coding work, life's too short to worry about retracing your steps --- it's much easier (and rosier) to try and remember what you 'think' happened and go from there.

One past client had a rule that all email was auto-deleted after two months ... sound horrific, but boy did it stop all the 'you said' 'he said' arguments... (also, stopped any horrible litigation :)

The killer app in all these years, as I transition from thinking like a coder to thinking like a mild alcoholic, has been Freemind, which helps me organise my thoughts and tasks but is practically useless for keeping a history of changes (ok, so it does, but the whole 'history' keeping doesn't work in mind maps). The thing about Freemind is that keeping information in a mind map somehow etches that same information in your brain - so I can remember almost exactly what's in my Freemind project map.

So, in summary, drink vodka...

Re:What Does It Need?

[Anonymous Coward]

1. Threading: They are working on some sort of non-blocking I/O scheme. Check the mailing list.
2. Try the "It's All Text" Firefox extension
3. gnus has a steep learning curve but it is as sophisticated a mail client as you can hope for.

Re:What Does It Need?

[Mr. Slippery]

I want to use Emacs for my editor boxes in Firefox, notably.

Have you tried mozex?

Re:What Does It Need?

[Mr. Slippery]

I never really searched through past email

I am, frankly, dumbfounded to hear someone say this. I find myself grepping old mail at least several times a month.

but I did lose archives during sync operations and missed having access to email when at the office. Gmail wins this battle every time

Gmail does not win the data loss battle every time.

As for access, all my personal mail (and also the mail from my current job) includes is in MH folders on my home box. I can ssh in from anywhere -- even from my phone -- and have access to e-mail archives going back more than a decade from MH, alpine, or standard command-line tools.

I promise to reply to emails quickly wherever I am if you promise never to ask me to remember what we talked about.

Ah. Well, if you never discuss anything worthwhile by e-mail, I suppose your needs are different.

Re:What Does It Need?

[Anonymous Coward]

I want to use Emacs for my editor boxes in Firefox, notably.

You can. Check out itsalltext at http://trac.gerf.org/itsalltext.
Perfect combo for wiki with wikimode in emacs.

Re:What Does It Need?

[tyroneking]

You know I wouldn't have responded except that you seemed to be levelling some criticism at me (and missing the 'I' point of view). So here goes with some unnecessarily vitriolic responses...

1. If I needed grep to find email then I think I would rather go to hell, which is where you obviously already.

2. Gmail may lose data but cannot believe that it does so as often as a regular user unless you are on crack.

3. If you can SSH from your work PC then you are probably breaking a whole load of company security policies and should be fired.

So, you are in hell, on crack, and soon to be fired.

I, on the other hand, am drinking vodka, have half a dozen laptops in various locations from where I can access all my email and documents without having to do a single thing.

Re:What Does It Need?

[Greyfox]

There is actually a mode for that. I use vi too, and your fingers will never forget those key bindings once you learn them. I mostly use vi for quick'n'dirty jobs like editing system config files and the like. Though I like syntax highlighting in emacs, I despise it in vim and prefer nvi (A bug-for-bug compatible vi that works like the old AT&T one) over the newfangled ones.

I did source code auditing at Data General back in the day and one of my co-workers got the code for vi assigned to him. This was the original AT&T vi, and he found todos in there from the early 70s. He also gained some respect for the editor and started using it, then started comparing how the Emacs vi mode worked versus vi. It's nowhere near exact but it should feel pretty familiar to a vi user.

Re:What Does It Need?

[Greyfox]

But Emacs CAN do code completion and code navigation! Most of that stuff is bound up in etags. You just have to turn it on (A lot of old makefiles have a "tags" target in them.)

Re:What Does It Need?

[Anonymous Coward]

Emacs is Perfect...

Well not entirely perfect, but I have yet to find a better editor for editing code. I keep my resume as a big lisp data structure which Emacs can use to emit into any markup language I care to write an emitter for (Currently HTML and plain text, but I've been pondering writing a LaTeX one as well.)

What I'd like to see in Emacs:

• Threading. Currently everything runs in one big thread, so if you try to do too much processing with elisp the entire editor hangs up. There was a push a while back to replace elisp with Scheme, which would solve this handily, but that effort sort of petered out.
• Better integration with GUI applications. I want to use Emacs for my editor boxes in Firefox, notably.
• A better mail client, or better integration with a GUI mail client. Emacs together with Remembrance makes for an awesome mail combo, but every time I've tried to do Email in Emacs, it's been a huge effort to keep it going.

Ultimately it would be nifty if Emacs could work as well with the GUI components on my desktop as it can with text mode UNIX applications, but I suppose that might be asking too much of it.

Hey! you stole this from my Lotus Notes wishlist!

Re:What Does It Need?

[onefriedrice]

One day I switched to Freemind and Open Office for documents and Gmail for email ... so terribly un-geek like, but so much easier.

I don't care one iota about the "geekiness" of a solution. If Gmail and OO.org works for you and you can get stuff done faster, that's wonderful. Personally, I did look back after I realized I can get so much more done in vim.

Re:What Does It Need?

[Anonymous Coward]

I always wanted to see a GTK+-2.x vim textbox.

Too bad readlines vim support is very limited.

Re:What Does It Need?

[tapanitarvainen]

I want to use Emacs for my editor boxes in Firefox, notably.

I am doing that right now, via "It's All Text" -plugin to Firefox. The most important FF add-on after Adblock+, IMHO.

Re:What Does It Need?

[EvanED]

You ignored what I said. Pure tags files suck because they don't pay attention to types, and I've never been able to get any of the fancier systems to work.

Re:What Does It Need?

[Vintermann]

> One of the main reasons why I stick to, in my case Emacs, mutt & similar tools is the extra options storing everything as (more or less) plain text gives me.

Since this is about editors and revision control... One little hack I did with my editor was to make it save all backups in a separate directory tree, make that a version control repository, and re-bind save so that it was save + commit. Crude, but it works. I don't like throwing things away :-) Scales just fine so far.

What's the vcs and editor? Mercurial and ... JEdit!
(JEdit is actually pretty sweet. Like Emacs, it has plugins for everything under the sun, and it has common bindings, so unlike emacs, you don't have to mentally task-switch when using a non-emacs editor/text field/moon phase indicator.

Re:What Does It Need?

[Vintermann]

Where do you draw the line between editor and IDE? If you want something sufficiently in between, some commercial editors have better solutions, yes. But there aren't all that many situations where you benefit from a code browser, but not from full-blown language support and systems that catch type/compile errors as soon as you edit the line.

Re:What Does It Need?

[akpoff]

Hacker paradox: anyone who can write: "I keep my resume as a big lisp data structure which Emacs can use to emit into any markup language I care to write an emitter for..." doesn't need a resume but if you hadn't done it you'd still need a resume.

— From another emacs geek.

Re:What Does It Need?

[Kidbro]

Good answer, thanks for taking the time to write it.

I remain unconvinced, but I certainly see where you're coming from :)
I will have a look at Freemind though, hadn't heard of it before you mentioned it.

Re:What Does It Need?

[tyroneking]

Glad you asked.

Make sure you give Freemind a try - it really is superb.

GIT vs Mercurial vs Bazaar

[harlows_monkeys]

Why GIT is Better Than X

Why Mercurial is Better Than X

Why Bazaar is Better Than X

EMACS discovers "distributed development"

[m6ack]

[Almost-a-troll]... but chooses an in-grown (GNU) tool instead of the best of breed -- i.e. git? Yeah... same-old, same-old RMS. Funny that BZR is now sponsored by Canonical...[/Almost-a-troll]

Re:EMACS discovers "distributed development"

[Vintermann]

bzr has been sponsored by canonical for ages. It grew out of Tom Lord's Arch project, which was the first serious attempt at an open source distributed VCS.

Re:EMACS discovers "distributed development"

[OrangeTide]

arch's command-line interface was worse than git's. And starting filenames with + was just a tremendous annoyance to vi users, I think it was done intentionally.

Re:EMACS discovers "distributed development"

[Anonymous Coward]

[Almost-a-troll]... but chooses an in-grown (GNU) tool instead of the best of breed -- i.e. git? Yeah... same-old, same-old RMS. Funny that BZR is now sponsored by Canonical...[/Almost-a-troll]

Git isn't universally superior to bzr. If there are non-technical reasons to choose bzr, there's no compelling technical reason to not to.

Re:EMACS discovers "distributed development"

[OrangeTide]

you mean other than Bzr is almost certainly going to fade into obscurity?

People have heard of git and mercurial. it's rare to meet someone who has heard of bzr. I realize it's not fair that it boils down to a popularity contest, and that we should weigh the technical merits. But that is never how it works, especially developer tool software.

Re:EMACS discovers "distributed development"

[Vintermann]

Because developers never have time to hang around on tech sites to watch the flamewars over which version control system is best?

Re:EMACS discovers "distributed development"

[OrangeTide]

Are you being sarcastic? Developers do nothing but have flamewars about tools. But it rarely is a technical discussion. And I like to think the flamewars don't actually accomplish anything in promoting one system over another. No the way that these tools becomes popular is a little mysterious and, in my opinion, not based primarily on technical merit.

Re:EMACS discovers "distributed development"

[Vintermann]

Oh, I didn't say it wasn't (and yes, I was being sarcastic). I'm just pointing out that as long as there are flamewars about hg, git and bzr, enough developers will hear about it that it won't fade into obscurity. All publicity is good publicity and all that.

I think the flame wars could even be limited to hg/git. If they lasted long enough, someone would probably be so convinced by their respective lists of each other's weaknesses, that they would look around for a "third way". For a revision system like bzr to actually fade away, something would need to happen of similar magnitude to what happened to old GNU Arch (abandonment by project initiator for personal reasons + mass migration to sister project, etc.)

non-joke versions of the last two

[Trepidity]

Why Mercurial?

Why Switch to Bazaar?

One feature missing from all of them

[harlows_monkeys]

There's one feature that, as far as I've been able to tell, is not in any of the major version control systems, whether distributed or not. That's good support for directory-based files.

What I mean by "directory-based files" are documents that are treated as a file by the applications that know about them, and the GUI system, but are actually implemented as a directory. The major example would be MacOS package files. For example, an OmniOutliner document actually consists of a directory with the name of your document, and in that directory there is an XML file with the outline and the files for any attachments to the outline, thumbnails of images, and things like that. In the Finder, the whole directory is treated as a file.

Verson control systems tend to see these as directories with files in them. This leads to a couple problems.

First, if you edit the document, and that causes files to get added to the directory, the VCS won't know that these need to be added to the repository. Same if your editing causes a file to go away--the VCS won't know it needs to treat that as a delete when you commit.

Second, if the VCS stores metadata in each directory (like Subversion does), and the application that writes the document uses the write/rename/rename/delete method of safe updating, it ends up making a new directory, blowing away the metadata.

I would love to see a VCS that handles these directory-based files automatically.

X / X.org is older, and moved there faster

[Anonymous Coward]

I worked with Jim Gettys, Keith Packard and Carl Worth to help migrate the X.org codebase to git, this was around January 2006 (at LinuxConf AU'06 and shortly after). According to JG, there are in existence ~25 years of SCM history, but the CVS repos imported dated from way back around 15 years IIRC.

~ m langhoff

Re:Wow, what quality...

[Kynde]

"Emacs's"

Take it from someone who has an "s" at the end of their name, it's supposed to be Emacs'.

Hardly, your case is far simpler, it's simply "Anonymous Coward's"

Take that from someone who actually read's both the posts and who wrote them.

How bazaar!

[Dachannien]

If this pattern holds, GNU Emacs will be in Bazaar for at least thirty-two years.

I'm pretty sure Emacs has already been bizarre for at least 32 years.

Why Bazaar?

[dmpot]

The answer is politics, politics, and politics... The subject of a modern VCS was brought by Eric Raymond, and he clearly favored to Mercurial. It seems most developers on the Emacs ML who were familiar with any DVCS were more inclined to choosing Git. I don't remember if anyone even mentioned Bazaar, before RMS announced that Emacs would migrate to Bazaar. As to justification for this decision, he said that Bazaar agreed to become a Gnu Project, and Gnu Projects should support one another.

Re:Wow, what quality...

[Anonymous Coward]

They taught us in school (in the USofA) that if the word ends in s or a s sound you add the apostrophe but never add another s. This is just another example of Wikipedia not knowing what it is talking about.

Now of course in common speech everyone adds the extra s sound.

What's the diff?

[Zero__Kelvin]

"the smaller the differences, the louder the arguments"

Yeah, you're right. What's the difference? git was designed by Linus Torvalds, has been used for more than 5 years on the largest FOSS effort in existence, and has the backing of some of the top software minds in the world, and Bazaar ... er, ah. Never mind.

Re:Wow, what quality...

[EvanED]

This is just another example of Wikipedia not knowing what it is talking about.

Because, after all, your school certainly did. And the Chicago Manual of Style (quoted in the references section of the Wikipedia article) also doesn't know what it's talking about. Right.