On Thu, Dec 09, 2021 at 06:29:14PM +0000, Kristofer wrote: > Hi Stefan and thanks for the hints. Then I need to line up a lot of > arguments, right? There's no "read from file" option that I can see. I'll try > that on the next failure, if I get one *fingers crossed*
Indeed, the list of path prefixes must be passed on the command line. Support for reading them from a file is not implemented, unfortunately. > Btw, I also have this really silly commit sequence where someone managed to > delete the entire branches/ directory followed by a commit that brings it > back (not sure if the commiter used a proper reverse-merge or a copy). I > haven't understood if that can be "fixed" with svndumpfilter or if there's > some other way to do it. Those two are basically a null operation, but it > messes with things like "log --stop-on-copy" I don't think there is an easy way to fix that via dump/load once other commits have been stacked on top. Any newer commit might refer to data stored in the problematic commit, due to deltification and other meta-data relationships between revisions. Copies in particular refer to node-rev-IDs which are generally hidden from the user, but which can be seen in the dump file, and which are not supposed to be changed. There is a commit in Subversion's own trunk history which unfortunately did exactly the same thing. But it is water under the bridge at this point. People rarely have a need to go far enough back in history to cross it.
