Did this problematic commit occur due to a bug at the time in Subversion or a user error?
Luke > On Dec 9, 2021, at 12:47 PM, Stefan Sperling <s...@elego.de> wrote: > > 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.
