Hi again, I tried what Stefan suggested below and used "svnadmin dump --exclude <bad path>" instead of piping it to svndumpfilter and I was tearing my hair out with failure until I realized that there's an undocumented difference here (at least I can't find it in the help text for them). For --targets file in svndumpfilter, I put the node as "rootDir/badDir", so I did "svnadmin dump --exclude rootDir/badDir" which didn't get rid of any of my problems. After some tears and bruteforcing it, I figured out you need the initial slash there, so "svnadmin dump --exclude /rootDir/badDir" does the trick. Just in case anyone else runs into this, remember the initial slash
On Thursday, December 9th, 2021 at 7: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.
