Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > That makes we wonder how we prevent packing in old format repositories. > We know that hotcopying while packing can corrupt the destination repo.
[...] > I'm -1 on reverting: Not being able to use hotcopy on an r/o repo is less > problematic than ending up with a corrupted copy. [...] > Once we are at it, let's detect pack operations during hotcopy (compare > pack status before & after the hotcopy). Then we can at least warn the > user of older format repos that their hotcopy is possibly corrupt now. [...] Could you please elaborate on this? What are the exact circumstances under which a concurrent 'svnadmin pack' for a hotcopy source makes a corrupted hotcopy destination feasible? A concurrent pack can result in the 'svnadmin hotcopy' erroring out with an ENOENT — in a situation when we attempt to copy a revision file that moved into a pack and was blown away in the cleanup happening in synced_pack_shard(). But even in this case the hotcopy destination is not *corrupt*, it is just incomplete due to how hotcopy currently checkpoints changes in db/current and in db/min-unpacked-rev (checkpointing occurs once per shard). The end user is going to have a quite visible error in this case, and calling 'svnadmin hotcopy --incremental' after receiving an error is going to copy the remaining part of the source repository and bring the target up-to-date — just as if nothing happened. I believe that if there are known circumstances that can provoke a corruption of the target repository during hotcopy, we should fix them, but I am currently unaware of these conditions. What are they? Regards, Evgeny Kotkov
