Version control
 

I'm just wondering off the top of my head: what version control systems do you guys use? At work, at home; I'm awfully curious as to see what you guys use.

Personally I use darcs for my Haskell work (because darcs is not only a great piece of software, but because it's somewhat ubiquitous in the haskell community,) and have recently started adopting git for the bulk of all my other work (I have used Mercurial however, only for a single project. The interface simply felt unnatural, although it did its job pretty nicely.)

For those who don't use revision control: I urge you to start. For those people (and those who're just curious as to other solutions,) here's a list of a few systems I recommend you try:
darcs
mercurial
git
And for those who use Subversion, but want a distributed revision control client, there is svk

And although I haven't tried bazaar or monotone, I've heard some good things about them (and bad things; namely, they're both somewhat slow and I believe revision control systems need to be fast; that's just my cent however,) and regardless, anything is better than CVS. :)

It's subversion here - and I haven't yet had a reason to complain. I have read about git but it's only for linux at the moment and at my job there's only Win.

But again ... I'm quite happy with SVN

I've been intrigued over the recent explosion of distributed version control systems...a few months ago I wanted to check out the gai...pidgin source, but was surprised to see that they'd switched to monotone. The Linux kernel of course has been transitioned to git. Why though? I've read over the docs for a few of them but still couldn't tell you what's so great about them. They all seem to be much more complicated to use than CVS or SVN, for one -- just reading the intro guides makes my brain hurt. Perhaps I'd just have to try them.

Git looks good to try...it seems well thought out. I would think there's also a healthy guarantee of continued support considering the high-profile project it is centered around.

But I stand by SVN for now. Especially on personal projects. If there aren't multiple people I fail to see any advantage in the distributed systems.

Out of curiosity, which of the ones you have tried make it easiest to nicely package up your local changes to attach in an email? I think that would be a big plus for me. (These systems don't let just anyone throw their code at the repositories...right?)

The basic idea behind a distributed system is everybody has a copy of the repository. Every repository may be different; this is not unusual, generally these repositories will be in this sort of an 'asychronous state.' Nobody really has 'the one repo,' and it's not expected for any one repo to be identical to another in terms of what commits are in them, etc.. Instead you pull changes from each other and give changes to others. They decide at that point how to apply them if they wish to.

Decentralized version control is exactly what it sounds like: there is no central core repository where tons upon tons of really important data is stored. When you think about it, this is a bottleneck in the design: if your central repository server goes down, your work is lost and down the drain (since the server contains all the really critical information.) In a distributed version control system, you can just get your work back from another repository and you're good to go. That simple.
Of course, naturally, you can set up an repo on the web which will be about as much of a 'central repo' as you can get in a system that's, well, decentralized. This really serves more as a single 'extraction and commit' point than anything else, it's just another repository that happens to be on the internet.

To answer the question in a basic form: no, you cannot just 'throw code' into some arbitrary repository. Naturally you're going to need permissions. This is how for example, you can have a repo on the web and push content to it from your client (normally you go through something like a authentication like SSH or somesuch to do this.)


To answer the other question about 'why git': the decentralized model is a much more appropriate model to something like the development of the linux kernel than a tool such as say, SVN; it would be an ill-suited choice (the subversion team themselves admit this.) More specifically, git was chosen (well, actually it was written by torvalds for linux) because linux needed a very very fast decentralized revision control system with good support for things like branching and merging. Git does these extremely well (branching support is absolutely critical if you ask me, once you try branches in something like git you won't want to go back to something like SVN. And for a project as huge as linux, almost no other revision control system is really fast enough to consider practical for usage.)

As for the *other* question about emailing changes: Darcs supports the ability to take a bundle of patches (these are 'commits' in something like svn/git,) roll them up in a file, and automatically email them to the maintainer of a repository.
This is largely how the Haskell community works (and this is how patches are submitted to darcs and how it is maintained): you have some software you want to hack on, pull a copy of the repo, make your changes, make a patch, email it to the maintainer. You can pull the patch file directly from the email and apply it to your repository. You can even set up your mail client (if you have one, like mutt) to automatically check for a PGP signature and if it's in your keyring then apply it automatically. The first part, involving sending the patch bundle is done with the command "darcs send" and that should be really all you need.


That probably sounded just like a lot of advocacy for distributed solutions rather than centralized ones like SVN/CVS etc, but it really makes an incredible difference in practice. Distributed version control solves *a lot* of problems simply by design and it gives you tons of flexibility. Here're a few things that distributed revision control offers (in general; many of the decentralized solutions have their own specific abilities/features, naturally):

- All working copies of the source tree are effectively branches in themselves. This makes merging as simple as just trading off patches between these two repositories
- Anybody can take part in the hacking. You don't need to have any sort of access to contribute; just get a working repository up and then trade patches with others.
- It's typically possible to 'cherry pick' out specific changes of certain patches and the like. This in particular generally varies from system to system, although darcs support amazing cherry picking facilities, simply due to the ideas it was based upon (patching theory.) This allows you for example, to make changes to the working copy, and make a commit, but specifically choose what goes in the commit and what doesn't. For example, if you're working and you add a feature but also fix a bug, it allows you to make a commit, but only for the bug fix, and then another for the feature addition, since the two logically belong in different commits anyway.
- Every copy is essentially a 'quasi-identical' copy of the code base (I say 'quasi' because like I said, not every repo will be completely identical, but they will probably share a fairly good amount of the same data regardless.) This means high data integrity, since there isn't just a single point of failure. If your disk gets corrupted you can get the changes from any other repo since the same data that was there before, is still there now.
- You can work offline. There is no need to be on the internet to make a commit and fix bugs, add features, etc.. Once you're back online, just push the changes to a 'central' repository (such as one on your website) and you're done.



It's worth noting however, where centralized wasn't good for the linux kernel, so is decentralized not suited for particular projects. In particular, I'm a perl 6 hacker and a pugs user. Pugs is a very very free-form project due to the fact perl 6 is entirely a community effort. A decentralized approach in this case would not have worked out as well: everybody needs the ability to be able to get their changes into the 'central' code base and make changes as they see fit rather than having everybody copying everybody's patches around and having to manually sort through every patch before it's commited to a repo that's on the internet that everybody else can pull from and get the code from, etc. etc.. For such a highly community-driven project, subversion was a good choice since commit access is handed out by simply asking and therefore getting your changes into a central location is quick and easy. This could have been done with a distributed version control system (and it probably would have had it's own good benefits,) but it would have ended up as a hassle overall I feel and subversion has worked well for such a community project where literally anybody can get into the repo and start working.




I hope that wasn't all wasted breath. It's really something you have to try before you can fully appreciate the beauty of the approach. If you want a really nice distributed revision control system that is easy yet powerful, I absolutely recommend darcs. It's highly advanced and has wicked features and abilities, but it has one of the most simple interfaces I've ever seen in a revision control system. Give it a shot and play around with it and I think you'll really start to appreciate the distributed approach to version control.

Edit: Since you use subversion I would also recommend you try svk. It's basically a distributed version control system layered on top of the svn filesystem, so you can do things like offline work and the like in a repository you've already been working with via vanilla subversion.

I'm keeping tabs on them. What I'm really waiting for is a frontend in the form of a file-manager plugin, like TortoiseSVN. It's just too useful.

Git has gitk which is amazingly useful in itself. Granted it might not be as 'pretty' as TortoiseSVN, but it's really nice in itself.

Mercurial has a Tortoise-like GUI in the works for windows, which from what I've seen, looks remarkably nice.


For the most part however, you'll be doing things simply from the terminal. This isn't really as much of a problem as you might think at first. Plus I find it easier from the terminal to really experiment with distributed version control. I advise that while a Frontend GUI like tortoise might not be available, you try darcs or mercurial simply from the command line first. While the interfaces might not exactly be as 'idiot-proof' as tortoise, the tutorials are simple enough to follow that you can start work with them after reading for about 5 minutes.

Here's a link to a Darcs tutorial, as well as the book on Mercurial that was written (which is pretty good):
http://wiki.darcs.net/DarcsWiki/GettingStarted
http://hgbook.red-bean.com/

Since you're using tortoise (ergo windows,) git isn't really much of an option I suppose. If you're ever on Linux however, I highly highly suggest you check it out for yourself (tutorial here.)

I don't do group development. I'm just a lonely kid (college freshman this fall) who works on pet projects. I usually don't use any version control except for large projects where I might screw up so badly that I can't fix it and need to revert back to a previous version. But hey, that's how you learn. When I used to work on my high school's website, I just tarballed everything. I'm working on a very simple OS kernel and my revision control for that is just a simple shell script that copies over my source files to a new directory and assigns it a build number. If I were to work on a real open source project, I would probably use git.

Here is a video of Linus Torvalds talking about git and why he feels it is the best version control system. It's a good video and Linus has a very unique but charming sense of humor. I've also noticed that he has lost weight since I saw him a few years ago (He got fat after moving to the US. Damn you McDonalds!) and his voice is very soothing. http://youtube.com/watch?v=4XpnKHJAok8