I'm pushing this off from 1.5 to a future version.

I'm also unassigning me.  Anyone is free to take this and work on it.

Talked with Blake on IRC.  Seems like it's going to be too magic to do it all in
one command, so instead, split it into three commands:

1. backup-mtime copies file mtimes to the metadata in the file for files that
don't have mtime in the metadata (probably want a --force to override)

2. restore-mtime copies mtime in metadata to the file

3. build-mtime-cache creates a cache file from scratch from mtime in the metadata


Also, this should probably be a plugin given that it's not clear that this will
match everyone's workflow.

You say:
   If the entry has no mtime in the metadata, this checks the cache and
   uses that.  If there's nothing in the cache, this checks the file's mtime.
   This adds the mtime to the entry metadata.
but I thought the primary use case would be to generate the cache.

I also think that the order of canonicality should be
metadata (most canonical)
mtime
cache (least canonical, but fastest)

So that would make the workflow look more like:
   If the entry has an mtime in the metadata,
     set the file's mtime and
     set it in the cache.
   If there's nothing in the metadata, get the file's mtime,
     add it to the metadata and
     set it in the cache.

Then, at entry display time, use the cache for items that are in the cache, and
the mtime for items that aren't.  (And possibly notify someone that we should
run sync-mtimes…)

Open Question: given the hopefully rare occurrence of cache misses, should we
check the metadata as well as the mtime if an item isn't in the cache?

PyBlosxom uses file mtimes for denoting when an entry was written.  This is
somewhat problematic for a few reasons:

1. it's easy to accidentally screw up the mtime of the file
2. it's hard to move files around without screwing up the mtime
3. if you want to store the mtime elsewhere (e.g. the metadata of the entry), it
becomes prohibitively expensive to sort entries by mtime at request time

Given that, we should add a new pyblosxom command:

pyblosxom-cmd sync-mtimes

   Goes through all the entries one at a time.

   If the entry has no mtime in the metadata, this checks the cache and
   uses that.  If there's nothing in the cache, this checks the file's mtime.
   This adds the mtime to the entry metadata.

   If there's nothing in the cache, this stores a filename -> mtime pair
   in the cache.


Then we can fix PyBlosxom so that it loads the cache file at request startup if
it exists and tries to do a lookup in the cache before restoring to the file mtime.