Slashdot Mirror
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 ..."
24 is plausible, too; an arithmetic not geometric progression.
You'd think there'd be an emacs keystroke combo to check for duplicate words in a block of text.
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!
So some young whippersnappers decide to change things around and this is news?
Get off my lawn!
Wasn't Emacs used as an example of a "Cathedral" project in Raymond's paper?
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.)
Is, the code for EMACS is written in vi.
* Carthago Delenda Est *
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.
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".
http://www.red-bean.com/kfogel
It's a matter of long debate among grammarians, and I take other grammarians's point of view :-).
http://www.red-bean.com/kfogel
So far what are the technical disadvantages to using Bazaar instead of git or something else?
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
Dilbert RSS feed
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.
Find free books.
It will be too late! --vi
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?
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
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:
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
Why Mercurial?
Why Switch to Bazaar?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
xkcd is not in the sudoers file. This incident will be reported.
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.
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.
Why use Git over Bazaar?
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.
Git is written in C by people with experience doing complicated things very quickly(kernel programmers).
Bazaar is written in python.
There are plenty of reasons.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
Somebody mod that up. That is an awesome rant of the best sort, one with experience, opinions, technical details, and examples.