GNU Emacs Switches From CVS To Bazaar 198
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 ..."
Re:Wow, what quality... (Score:5, Informative)
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 [wikipedia.org]. (In particular, that article makes it sound like the Chicago Manual of Style recognizes both forms as valid.)
Re:Why 32? (Score:2, Informative)
Ok, that's fair -- it could go either way. That's what I get for trying to be too clever!
Re:Cathedral & the Bazaar? Irony? (Score:1, Informative)
IIRC Raymond's examples for the cathedral model were primarily closed source software from big companies, particularly operating systems. Not emacs.
Re:32 years? (Score:5, Informative)
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 [versioncontrolblog.com]
Re:what's new?; bazaar versus git (Score:4, Informative)
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:Cathedral & the Bazaar? Irony? (Score:5, Informative)
Re:32 years? (Score:5, Informative)
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? (Score:5, Informative)
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:what's new?; bazaar versus git (Score:3, Informative)
non-joke versions of the last two (Score:5, Informative)
Why Mercurial? [red-bean.com]
Why Switch to Bazaar? [canonical.com]
Re:Cathedral & the Bazaar? Irony? (Score:3, Informative)
Re:32 years? (Score:5, Informative)
I lost data [dlitz.net] as a result of bzr not supporting history rewriting. As far as I can tell, it's still not supported [launchpad.net].
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? (Score:4, Informative)
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.
X / X.org is older, and moved there faster (Score:1, Informative)
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:ObSimpsons (Score:3, Informative)
Re:Why not git? (Score:4, Informative)
There are plenty of reasons. [whygitisbetterthanx.com]
Re:What Does It Need? (Score:2, Informative)
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.