Fw: svndumpfilter: finding source commit for error?

[Kristofer <gu...@protonmail.com>]

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 <st...@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.