metastore/FILEFORMAT_1, branch format1-3 File metadata backup/comparison/restoration tool Add ability to not save mtime in metadata files 2022-05-24T09:12:33+00:00 Adam Spragg adam@spra.gg 2022-05-18T15:35:35+00:00 7292804c1bafd43389defc0d7b4352ada666d626 If you're storing metadata in a version control system with multiple branches, mtime differences are going to produce a whole bunch of conflicts that you likely don't care about. This allows you to not save mtime and avoid those. Note that we use a sentinel value of -1 for the mentry `mtimensec` field to indicate this in the data, as all values of `mtime` are theoretically valid, but `mtimensec` must always be between 0 and 999,999,999 in the real world. I'm not 100% sure about the mechanism for selecting this feature. The legacy behaviour for metastore was to save mtimes in the metadata files, but ignore them for compare/apply by default, with a `--mtime` option to use the mtime data. Keeping the legacy behaviour for backwards compatibility, but adding a `--no-mtime` option to ignore mtimes when saving felt like a reasonable way of making this happen, but something about it doesn't feel great. Maybe I just didn't figure out how to make the documentation clear enough. ¯\_(ツ)_/¯ 
If you're storing metadata in a version control system with multiple
branches, mtime differences are going to produce a whole bunch of
conflicts that you likely don't care about. This allows you to not
save mtime and avoid those.

Note that we use a sentinel value of -1 for the mentry `mtimensec` field
to indicate this in the data, as all values of `mtime` are theoretically
valid, but `mtimensec` must always be between 0 and 999,999,999 in the
real world.

I'm not 100% sure about the mechanism for selecting this feature. The
legacy behaviour for metastore was to save mtimes in the metadata files,
but ignore them for compare/apply by default, with a `--mtime` option to
use the mtime data.

Keeping the legacy behaviour for backwards compatibility, but adding a
`--no-mtime` option to ignore mtimes when saving felt like a reasonable
way of making this happen, but something about it doesn't feel great.

Maybe I just didn't figure out how to make the documentation clear
enough.  ¯\_(ツ)_/¯
Sort entries in Format 1 files by path, ASCIIbetically. 2022-05-18T16:19:47+00:00 Adam Spragg adam@spra.gg 2022-05-18T09:42:10+00:00 ce62a76e4570b6368384b3995c1ba106389df454 This ensures that the files are stable, and not subject to the order in which the OS returns directory entries. This should prevent unnecessary changes, and therefore unnecessary merge conflicts. 
This ensures that the files are stable, and not subject to the order in
which the OS returns directory entries. This should prevent unnecessary
changes, and therefore unnecessary merge conflicts.
Add documentation for new Format 1 2022-05-18T16:19:40+00:00 Adam Spragg adam@spra.gg 2022-05-17T09:44:27+00:00 588b3e780fef14631f7ec5c369bff07efdc5e013