I work on, among other things, Chromium. It uses SVN as its revision control system. There are several drawbacks to this, which are well known (no offline commits etc). They are made worse by Chromium’s enormous size. An ‘svn update’ can easily take over an hour.
Recently I looked into using btrfs’s features to make things easier. I found that with very little effort you can make things much more workable.
First you create a btrfs subvolume.
btrfs subvolume create chromium_upstream
Then you check out Chromium to this directory using the guidelines given in their wiki. Now you have a pristine upstream SVN checkout. Then build it once. No development is done in this directory. Instead we create a new directory for our work.
btrfs subvolume snapshot chromium_upstream chromium_feature_x
And roughly three seconds later you have a fresh copy of the entire source tree and the corresponding build tree. Any changes you make to individual files in the new directory won’t cause a total rebuild (which also takes hours). You can hack with complete peace of mind knowing that in the event of failure you can start over with two simple commands.
sudo btrfs subvolume delete chromium_feature_x btrfs subvolume snapshot chromium_upstream chromium_feature_x
Chromium upstream changes quite rapidly, so keeping up with it with SVN can be tricky. But btrfs makes it easier.
cd chromium_upstream gclient sync # Roughly analogous to svn update. cd .. btrfs subvolume snapshot chromium_upstream chromium_feature_x_v2 cd chromium_feature_x/src && svn diff > ../../thingy.patch && cd ../.. cd chromium_feature_x_v2/src && patch -p0 < ../../thingy.patch && cd ../.. sudo btrfs subvolume delete chromium_feature_
This approach can be taken with any tree of files: images, even multi-gigabyte video files. Thanks to btrfs’s design, multiple copies of these files take roughly the same amount of disk space as only one copy. It’s kind of like having backup/restore and revision control built into your file system.