unison
unison copied to clipboard
bcpierce00
Enable placing archive files in a different directory than config files
Archive files and config files sharing a common directory is problematic for various reasons (need to add pretty crude patterns to .gitignore, etc)
I'd love a --archive-root or similar option to relocate archive files to another directory away from my config files.
This makes a lot of sense to me. I lean to just having a separate directory for data, not configurable, as a first step to get 90% of the gain with 10% of the coding. I am guessing that adding ~/.unison/db to your ignore list once would be ok.
That would definitely be a great improvement.
Although it wouldn't solve my original issue - I keep my dotfile directory synced with Apple iCloud Drive so my .unison directory contains archives from all my machines. These files don't need to be synced at all.
Keeping config and archive totally separate would certainly help. In a perfect world I'd love to see adoption of "XDG Base Directory Specification" (paths would default to ~/.config/unison and ~/.local/share/unison perhaps) - a lot of other tools are now following this standard (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) But understand that's probably more work :-)
I see; multiple sync methods tend to fight each other no matter what. Perhaps a first step is to make each configurable with an env var, avoiding most everything including needing a transition plan. But someone(tm) will need to prepare and test a patch.
A fair point about XDG, modulo figuring out the intersection of "desktop" and traditional command-line tools. Also .local/share is bizarre, but precedent is precedent, and I agree with your reading of the spec. We'd also need a story about macOS and Windows, but presumably that's well-trodden ground.
In addition to configuring the directory, it should be possible (and perhaps the standard approach) to put ar/fp files in the directory being synced. This follows the principle of fate sharing, where metadata stays with data so they are, to first order, lost or not lost together. It would also mean that running test syncs and then removing the roots would clean up the fingerprint/archives.