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.
Why use Bazaar over Git?
--------- I have no signature
It will be too late! --vi
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 :)
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!
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 :) ).
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.
All your base are belong to Wii.
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?
Why GIT is Better Than X
Why Mercurial is Better Than X
Why Bazaar is Better Than X
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.
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.
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
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.
“Common sense is not so common.” — Voltaire
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.
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.)
"Little does he know, but there is no 'I' in 'Idiot'!"
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.
The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
Now get off my lawn!
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.
Git is written in C by people with experience doing complicated things very quickly(kernel programmers).
Bazaar is written in python.
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.
Don't thank God, thank a doctor!
If it's not an architectural/design issue, then the bits that are slow could be rewritten to be faster.
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.
Somebody mod that up. That is an awesome rant of the best sort, one with experience, opinions, technical details, and examples.
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.
“Common sense is not so common.” — Voltaire
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?
Yeah. Would you choose a neurosurgeon who pokes around people's brains in his spare time? I wouldn't.
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.
Yeah, great point. Linus and all the rest of the kernel developers aren't that bright. We should listen to you.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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/.
Life is just nature's way of keeping meat fresh.
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.
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.)
Don't thank God, thank a doctor!
As they are in Mercurial.
xkcd is not in the sudoers file. This incident will be reported.
Because developers never have time to hang around on tech sites to watch the flamewars over which version control system is best?
xkcd is not in the sudoers file. This incident will be reported.
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.
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:
While it's annoying in that it'll prompt you "are you sure" with every file, it still does nothing to prevent this:
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.
Don't thank God, thank a doctor!
Giving it a shot, seems straightforward. Thanks
Yeah. Would you choose a neurosurgeon who pokes around people's brains in his spare time? I wouldn't.
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.
“Common sense is not so common.” — Voltaire
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.)
xkcd is not in the sudoers file. This incident will be reported.
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)