Version Control
I’ve recently begun moving more or less all of my digital documents into a version control system (using Subversion). This sounds a little geeky and esoteric, and is in implementation, but I think it’s something that would benefit almost everyone who uses computers frequently.
The basic idea is that whenever you make a new version of a file, you submit that file to the version control repository, and it stores it along with all previous versions. I used to have manual equivalents of this, as many people do, where I would start with document, it would spawn document2, document2a, document2b, document3, document_final, document_final2, document_final2_revised, etc. Believe me, once the setup overhead is done, dealing with a version control system is far better.
Centralization is a significant advantage, too. It’s a lot easier to simply back up the repository, if you keep things checked in to it, than either backing up all the named versions, or (worse) trying to just back up the current version.
Version control systems (or “revision control systems”) are extremely useful for software projects, where you might make significant progress before discovering that development took a wrong turn a while back, and the whole thing needs to be rolled back to several versions ago. Most version control systems are designed with this in mind, and keep track not merely of individual file versions, but of versions for the entire project.
Working on multiple machines makes version control extremely useful also. Without it, you have trouble synchronizing the files between the different work environments, something that has been a significant headache for me in the past.
I anticipate that it’ll make things easier not just for my code projects, but also for my writing, where keeping track of different versions of things has been a real pain. I don’t think it’ll suddenly make me finish my novel, but getting the novel under version control will make tackling it a lot easier.
Because I haven’t been using proper version control (or properly-organized backups) for my whole life, but instead have a long trail of renamed files/directories, zip files, random stuff shoved onto CD when I got scared of hard drive crashes, etc., it’s not going to be easy to just reorganize that into something that’ll fit neatly into a repository. And to properly harness the power of version control, I need to do that reorganization, and essentially go back, and check in stuff from ten years ago, then check in stuff from eight years ago as a “version”, then seven years ago, and so on–recreating retroactively the “history” of my versions. This is likely to be awkward, and Subversion isn’t really designed to accommodate that (nor is any other version control system I’m aware of).
Right now, the broad categories I’m using are:
* code
* config
* graphics
* misc
* personal
* web
* writing
I just added the “writing” category as I was writing this post: in the directory hierarchy I’ve been using for years, my for-eventual-publication-of-some-kind writing is stored with other personal stuff like morning pages, letters, etc., and so I just included it within the “personal” section. But that doesn’t really make sense once I’m doing proper version control, and in fact major writing projects might need their own repositories (because repositories are considered “projects” by the system). For the moment, however, those are the categories, and they can be split out further if necessary.
I’m only at the beginning of moving my stuff into subversion, and it’s already made a difference in my work on this website (the code, not the posts… that’s another story) and on sfmagic.org.
Also, once I do have every file I really care about under version control, I can then make my (currently non-existent) backup process far easier, as noted above. And that will be a relief—backups are important!