Why did you use variable chunks when we already know that those don’t work with databases? Or maybe I should ask: why did you use a repository with databases for the tests?
I tried to figure out what the the two alternative versions of duplicacy do differently but I couldn’t. Do you understand them?
But I noticed that the file boundaries version has some recent “tweaks” added. You might want to check if those affect your tests. In any case, it probably makes sense if you link (also) to the exact version that you used, rather than to the (current version of the) branch.
@gchen I’m wondering what might be a good way of handling duplicacy’s strong reactions to certain kinds of changes in the repository (i.e. the kind of changes that a database reindexing causes). What I mean here, as opposed to some of my previous questions, is how to detect and handle extreme situations, i.e. where a new snapshot has caused a significant increase in storage use.
At a very basic level, I wonder if it would be possible to make duplicacy automatically tag such snapshots for easy identification? The point would be to deliberately target the preceding snapshot with the prune command. In other words, what I’m heading for is to optimize pruning instead of (or in addition to) optimizing backup. Does that make any sense?
At a more advanced level, duplicacy could routinely compare the increase of the repositorysize with the volume of uploaded chunks and issue a warning (or tag the snapshot) if that ratio becomes to big.