Adventures in Source Control
Posted in Misc on Fri, June 6, 2008 at 02:30 AMWay back in 2006 I had an interesting email conversation with my friend Jeff Hansen about Gentoo Linux, source control, and other things. I used to work with Jeff back at the TALL Group. He now works for a company called Card Access doing Linux kernel development. (He's also a genuine, real-life Nintendo World Champion--for 3 years in a row.)
Anyway, Jeff asked if I'd ever tried git for version control. At the time, I was still using CVS. Not long after that I started using Subversion and left CVS behind for good (thank goodness). Subversion has worked out relatively well for me over the past few years, and it was such an improvement over CVS that I never really gave serious thought to looking at anything else.
git has since come up in a few conversations with both Jeff and another friend in recent months, and as a result I've had an item on my mental to-do list to investigate it. Over this past weekend I finally took some time to read up on it. I also watched a rather lengthy, but quite informative presentation that Linus Torvalds himself gave on git at Google. You can watch it here: Tech Talk: Linus Torvalds on git.
I've read that Linus likes to ruffle feathers, but it's funny actually seeing him do it instead of just reading about it. git came about because Linus was looking for a source control system to replace BitKeeper that met certain criteria (distributed, fast, etc.) and decided that everything out there was crap. He states: "The end result was that I decided I can write something better than anything out there in two weeks, and I was right." He slams CVS, Subversion, Perforce (which I have never used), and pretty much every source control system out there except git (obviously) and Mercurial (which I have also never used).
At another point in the video, he says, "You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly, so keep that in mind." Probably the most confrontational thing he did was to call the designers of Subversion morons, and then directly calling any Subversion contributors in the audience "stupid." (These quotes are taken from a transcript of the video.)
Linus' interesting personality aside, I've found a lot of aspects of git really intriguing. His technical arguments on all of the major points are really solid. I've actually been playing around with it and there are a few things that I really, really like:
- It really is FAST. Unbelievably fast. I was skeptical at first, but no longer. It's waaay faster than SVN.
- Branching and merging really are easy, just like Linus claims. I actually imported one of my SVN repositories into git and did a merge of two branches there that I had been putting off, and it went swimmingly.
- I really like being able to continue working on the repository while offline. I don't know how many times I've copied a Subversion repository (in addition to the working directory) to my laptop so I could continue working on a project without net access.
Some other things I like about git, but which I haven't verified or played around with yet:
- Because it's distributed, you don't have to worry about commit access to a central repository. This seems really, really cool.
- The storage format is supposed to be very efficient due to compression and some other things.
- git actually tracks the content in files, not files themselves, so apparently you can track the history of specific pieces of code even if that code gets moved between files.
- git guarantees your data integrity. Given a single SHA1 commit identifier, you can verify that your entire project's data is exactly the same as when it was committed, so nobody can come in and corrupt your repository without you finding out about it.
- git has a command called bisect, which helps you track down the specific commit at which a bug was introduced. Basically it helps you do a binary search on the project through time, which cuts down on your reproducing time until you actually find the bug.
git seems really promising, and I'm going to keep playing around with it. I never thought I would find a compelling reason to switch from Subversion but I might just be wrong!
18 comments:
Thats a very interesting piece of software you talking about 8) Im gonna give it a try.
As a speaker, I can't help but think that Linus is just an idiot. Ya, he's a smart guy and such and I'm sure that he's just trying to be funny, but I think that it usually just comes across as lame.
I've actually been pretty interested in git, because at work we use a task based versioning system call Synergy, and even though it basically sucks, the merging and such capabilities of it are VERY interesting. I should definitely give git a try some time, and I've also heard that Bazaar is pretty cool. Because as much as I love Subversion, I have to admit that it's merging capabilities are basically non-existent.
As long as Linus continues to innovate in technical areas, I think it's worth taking a look at what he produces and ignoring his negative personality traits when necessary. Luckily neither Linux nor git has interrupted its normal function to let me know that I'm stupid and ugly :-).
I highly recommend trying out git though...I think I'm pretty much sold at this point. There's a slight learning curve, mostly from having to train your mind to get away from the central repository concept.
Heh, most of my problems are not with the git learning curve, but with the fact Im not familiar enough with linux style apps. Which as well means that I have to run git in windows O.O And the very first thing I stuck at was (and is) committing - how the hell do you submit that freaking commit message after editing?! >_< I had to use git-gui to avoid that stuff, and git-gui is kinda limited 8(
I know that part of it is just lack of familiarity, but I think that a lot of times some open source stuff just plain sucks when it comes to user interface/ease of use. I guess that the old "you get what you pay for" thing just applies here.
SVN 1.5.0 was just released and has the beginning of support for Merge Tracking, so hopefully that will bring it to being more on par with tools like git.
I was just doing some reading on distributed version control systems and the thing I don't get is where is the "central repository". I realize that there technically isn't one and that that is part of the big appeal, but, for example, if I want to get a copy of the Linux kernel, where do I go? I found the list of git repositories for the Linux kernel, but which one is the "official" one and how are all of the changes in those repositories coordinate to make the final product?
Linus talks about this in the Google Tech Talk. Basically, once you become distributed, it becomes all about who you trust. Since Linus is the "benevolent dictator" of the Linux kernel, he maintains the "official" repository, which gets cloned/pushed to various other distribution locations. He also chooses which changes to pull into his "official" version, thereby making sure quality remains consistent.
I think most projects would require a central location of some kind, or else a trusted person to maintain a trusted tree. Still, I don't think this negates the advantages of a distributed system. I've switched to git now and push all of my changes to a single server, but being able to work just as effectively without access to that server at any given time is awesome.
How does he find time to merge in all of those changes? Or is it a complete trust thing and he just has a group of people that if they "submit" a change, then he accepts it? It just seems like a TON of work (especially for a project as massive as the Linux kernel).
He has a few "lieutenants" that own the major subsystems. He trusts them to merge stuff that they feel really good about for their respective areas, and then he pulls changes from them into his tree. It's certainly got to be a tough job, but they all seem to do pretty well at it.
So I finally watched the whole Tech Talk by Linus on git, and to be completely honest, I wasn't impressed. I had actually been pretty enthused by the stuff I had read about DVCS systems (like git, Mercurial, and Bazaar), but Linus just ignored and glossed over so many of people's "tough" questions by making some stupid joke or by repeating "doesn't CVS really suck at branching?".
Maybe I'm missing something, but Linus just comes off as stupid/ignorant half the time with his jokes and "strong opinions". I will definitely give a DVCS a try (probably Mercurial instead of git) and the pros seem to outweigh the cons, but it's FAR from the "perfect system" that Linus blindly claims it to be.
Yeah, he's pretty abrasive. Still, after trying git myself, I'm fairly convinced. The speed and the ease of branching and merging haven't disappointed. It's not perfect (is anything?) but it's a step above anything I've ever used before.
Linus is a smart guy, but I'm glad I don't work with him.
I know that we already went over this, but I believe that Linus did an amazing thing by starting Linux (and basically kick starting the whole open source movement) and maybe I'm just not familiar enough with his work or blinded by his ultra-annoying personality, but I just can't really buy into him being smarter than any other programmer out there. He probably is a lot brighter than he comes off, but his comments are just so one-sided and make him appear ignorant/stupid. I guess I just believe that expression is a major component of intelligence (at least meaningful intelligence), and that an area in which Linus is lacking.
Having said that, I'm definitely gonna give the whole DVCS a try, because it seems like a cool idea and I can definitely see the potential advantages (because like you said, nothing is perfect, so it's just selecting the tool whose pros most outweigh its cons and which most fits your task).
I just imported an old Subversion repository with some branches into Mercurial and then started playing with it (I REALLY like that the Mercurial interface is identical to the Subversion interface whenever it can be). I then did a merge and all of the changes from the branches were instantly in my "trunk". I was BLOWN AWAY. It really did take a headache of a task and neatly processed all of the data for me while showing the correct information in the history/log.
So maybe Linus' bold statements have some more weight than I was giving them credit after all.
I just noticed one thing that I can do with Subversion that I can't do with Mercurial.
With libraries, I usually have a "code" folder that contains the the actual library and then a "test" folder that contains code I use to test/develop the library. Then I can just checkout the "code" folder in the programs that I use the library without having to mess with all of the test/development code.
Not a big deal, but it's just a minor inconvenience that means I'll probably have to do a little restructuring in my libraries.
I just switched to git. Currently, I have no regrets 8)
I have always wanted them to add support for an "uncommit" command to a VCS. Obviously, you can pull off a similar effect by just undoing the change by hand and then recommiting, but with a task-based system like the DVCS it would be pretty simple to actually have an uncommit command. I mean you could even keep the data in the repository by having it turn into a closed branch or something that just wasn't merged into the trunk. There's always potential for conflicts (a line that you want to remove that was editted later), but you could just resolve that using the same conflicting resolution type of idea that's applied during a merge.
How useful or common this would be is definitely up for debate, but it's something that I've always thought would be a very useful feature.
From what I've read, Bazaar actually has an "uncommit" command, but it appears that it only removes the most recent commit, so it can't do what I was hoping it could.
With git you can completely undo a commit, which I think is what you're describing (except that the history is gone forever--it doesn't stick those changes into a closed branch or anything like that). Not sure if it only works on the most recent commit or not.