[Unison-hackers] reconsidering the backups concept

[Greg Troxel]

unison has a concept of making backups, but this is awkward because:

  1) They are sometimes put in a different place than the replica (could
  be different security properties, could have different space issues).
  I think this shouldn't happen, at least by default.

  2) The scheme is simplistic and there is no eventual garbage
  collection of no longer needed backups.  Of course, software can't
  tell what the future holds and "no longer needed" is tricky business.
  I'm not really sure what to do here, even ig there were cycles to do
  it.  My own approach to backups is to keep them indefinitely and buy
  more disks over time and at some point decide they are so old they
  don't matter.   Because I generally back up the contents of replicas,
  and don't run -auto, I have never turned on unison's mechanism.

  3) The interaction of backups for merge and backups on delete/modify
  is not easy to understand, and may not be the best choice.

It might be that it would be good to have "backupmaxage", defaulting to
off, but settable to e.g. 1 year, that causes unison to periodically
scan replicas (when syncing, not every time) and remove backups that
were created too long ago.  It might be that this has consequences we
don't like -- I don't really know.

I don't intend to work on this, because it solves a problem I don't
have, but if someone does, please feel free to discuss here, especially
if you're willing to write code, write manual text, and write tests.