Change location of codebase backups

[ceedubs]

Is your feature request related to a problem? Please describe.

Currently before ucm performs a codebase migration, it copies the sqlite file into the same directory, so you end up with something like:

~/.unison
└── v2
    ├── unison.lockfile
    ├── unison.sqlite3
    ├── unison.sqlite3.v15.1715866536
    ├── unison.sqlite3.v15.1715867814
    └── unison.sqlite3.v16.1720743231

There are a few reasons that I don't think this is a great place to put the back up files.

Firstly, it isn't obvious what they are. If they were in a directory called backups (or something similar), I think their purpose would be more obvious and people might realize that they can delete them if all is good with their codebase.

Secondly, it's a bit awkward to remove them. You can do something like rm unison.sqlite3.*, but I find it a bit anxiety-inducing to ask myself whether I'm about to accidentally erase my codebase.

The third reason is a bit more niche. I have some Docker builds that need to bind-mount the Unison codebase into the build context. As of now, Docker won't let you do this with an individual file; only a directory. So I end up mounting ~/.unison or ~/.unison/v2, which ends up including all of the backup sqlite files, which causes a lot more data to be copied into the build context. For example my sqlite file is currently just above 500MB so if I have 3 backup files then I end up copying 2 GB into the Docker build context every time that I run docker build. I can easily accumulate 200GB of garbage for docker system prune in a day 😱 .

Describe the solution you'd like

I don't have a particularly strong opinion on where to put backup files instead. If they are going to stay in the ~/.unison directory, then maybe it could look something more like:

~/.unison
└── v2
    ├── unison.lockfile
    └── unison.sqlite3
└── backups
    └── v2
        ├── unison.sqlite3.v15.1715866536
        ├── unison.sqlite3.v15.1715867814
        └── unison.sqlite3.v16.1720743231

Or maybe there is some XDG base directory that makes more sense.

Describe alternatives you've considered

An alternative approach would be to automatically delete these files if everything looks all right after the migration. But this seems risky because there might be a bug that prevents us from knowing whether everything is all right.

We could probably assume that gc is safe for files that have been around for more than a month or something, but in that case I'd still want this feature so they aren't cluttering up my Docker context in the meantime.

Additional context

Yes, additonal context is exactly the issue that I'm reporting 😁