I’ve been using
rsync to build my site as a combination of a base layer
git plus an overlay generated using
Nanoc. Here’s how.
Each time the new site overlay is generated,
rsync gets called as
$ rsync -avr --no-times --delete --checksum --files-from=deploy/files \ output/ $DESTINATION
This takes an overlay from
output/ and writes it onto the
The overlay is specified by
deploy/files, which contains a list of the
files and directories forming the overlay, including:
/.htaccess /404.html /assets /blog /photography /there
rsync options are of course the real meat of this:
-ameans “archive mode”; this means that things like file modes are copied across.
-rmeans “recursive”. That would normally be implied by
-a, but it is suppressed by default when using
--no-timesstops the copying across of the modification time for files that have not themselves been modified. Creation and modification times have no meaning when we’re regenerating the entire overlay so frequently.
--deleteforces deletion of files in the destination that are no longer part of the overlay.
--checksummeans that we don’t look at things like file creation and modification times to determine whether a file has changed. This means that
rsyncbehaves more sensibly in an environment where all the files are being regenerated every time; only the ones whose contents have been changed will be copied across again.
I’m not far from the point where I will want to reverse this arrangement. At
that point, I will be copying across the entire contents of
protecting only selected files in the destination. It looks like the
protect rules will be the way to go for that. Fortunately
--dry-run option to allow for experiments.