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!
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.)
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.
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
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!