Being a college student means that I have to write papers every now and then. And writing papers means multiples drafts and lots of changes. Normally this would mean having lots of documents having each with a different version of the paper. While this lets you look up all the different versions quickly, it also means that you’ll quickly have a folder filled with lots of files with different and often conflicting names, making it rather hard to find the one you want.
Enter version control. Programmers (especially open source ones) have been using version control for years to manage the various revisions that they make to their source code. If you’re willing to get your hands a bit dirty, then you can easily leverage any of these robust and powerful systems to manage your everyday documents. There are a large number of version control systems to choose from. The old favorite was Concurrent Versions System CVS, but it has been largely superceded by Subversion. Subversion is extremely popular in the open source world, and it is the system that drives Sourceforge. Both CVS and Subversion are centralized systems, i.e. there is a central copy of the files (called the repository) and everyone who wants to make changes has to check out a working copy and then sync changes back to the central repo. There are also a number of decentralized or distributed version control systems including git (used by the Linux kernel) and lightweight alternatives like Mercurial.These do not require a central repo relying instead on a peer-to-peer approach to keep differing copies in sync.
So which one is right for you? If you use one computer and are not particularly interested in keeping things synchronized between multiple machines, one of the centralized systems would be sufficient. But if you need multiple machines (and use them all frequently) you should look into the distributed systems. I have a PowerMac desktop and a Linux, however I tend to use the laptop more. I went with Subversion, turning my Mac into a lightweight Subversion server, housing the central repo and working copies on both machines.
Though the systems will have different ways of setup and management, they are still quite similar in the way they require you to add, change and sync files, so you should not have much trouble moving and adapting once you get used to one of them. Tomorrow I look into setting up a simple subversion server and using it get files out to another machines (and then synced back).