Keeping $HOME (or /etc) in Subversion

• Synchronization: First, it allows you to easily synchronize common files between computers or accounts. Subversion is not the only tool for this, but is the most appropriate for some types of use, such as $HOME. For other uses, I recommend unison. Unison is a great tool for synchronizing large files such as music. It also helps with trees which don't benefit from history, or can change a great deal in a short time, such as Maildirs.
• Backups: Second, it acts as a distributed backup mechanism. The best backup systems have three properties: They are easy, so you actually do the backups regularly. They are spread across several machines or locations, so a given disaster doesn't knock them out. And they are tested on a regular basis, to make sure the backup works. You will get all three, as a side effect of using subversion. Just make sure to "svn commit" every day, and you can sleep safely with the assurance that you won't lose your data. You should still probably back up the repository, so you won't lose your history, but that is merely an extra precaution.
• History: Third (and probably least important), it provides revision control so you can retrieve older versions. This can be useful for the same reasons it helps with source code, but mostly I find I use it to "safely" delete files without worrying that I might need them again someday. If I change my mind later, I can still get the file back. It helps me keep my $HOME clean.

	% svn up
	Fetching external item into '.common/bin'
	External at revision 514.

	At revision 514.
	% vim todo.txt
	% svn stat -q    # [q]uiet; does not show unversioned files
	M         todo.txt
	M         .zshrc.local

	Performing status on external item at '.common/bin'
	A         newscript
	% svn ci todo.txt -m "finished project foo"
	Committed revision 515.
	% svn ci .zshrc.local -m "added new mplayer alias"
	Committed revision 516.
	% svn ci .common/bin/newscript -m "makes some random task easier"
	Committed revision 517.
	% svn stat -N    # [N]o recursion; only current directory.
	?         tempfile
	% rm tempfile
	

• Too big: I don't keep my music or video collections in svn, because they're simply too large. I don't have enough disk space to store all my anime on hard drives, much less three copies of it (one in the repo, two in each working copy). Besides, the revision features of svn would be of very limited value for these files.
  
  I find rsnapshot useful for doing backups of large file collections, and unison useful for synchronizing the files between hosts. For example, I have a zsh alias set up to make unison synchronize all music by a specified artist, so I can copy parts of my music collection to my notebook and back without having to copy the whole set.
• Too many: I don't keep my email in svn either. I use Maildirs, which means one file per message. I receive at least 50 messages per day, on a slow day. Keeping it in svn would require either manually adding all those messages, or making a script to do it for me. And even worse, it would make moving messages around more difficult. My email client could probably be configured to "svn mv" files instead of using its regular move method, but that seems like more effort than it's worth. And again, history is of limited value here. I don't go back and edit messages later, so the files never change.
• Not valuable enough: I don't keep system files or temp files in Subversion. There's no point in keeping /usr/bin/emacs under revision control, for example. And I have quite a few "scratch" files laying around which never make their way into svn. I don't bother tracking any files I don't care about.

• svex: aliased to svn pe svn:externals
• svig: aliased to svn pe svn:ignore
• svst: aliased to svn stat -q | grep . | grep -v ^Perf