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*
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" ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 9th, 2021 at 7:08 PM, Stefan Sperling <s...@elego.de> wrote: > On Thu, Dec 09, 2021 at 05:07:09PM +0000, Kristofer wrote: > > > And of course, soon after mailing, I found a workaround. I am not sure why > > it worked but anyways: > > > > The problem was caused by the branch being merged to trunk, but the > > contents of the "bad directory" was never merged. Then I thought it would > > be fine to filter out the bad directory itself, especially since there were > > no subtree mergeinfo on it. > > > > But it turned out that I could filter "baddir/badcontent1" and > > "baddir/badcontent2" and then the dumpfilter operation worked fine. I still > > don't know which revision the actual problem showed up, but it doesn't > > matter at this point :) > > > > I suppose there is something with the mergeinfo that I do not understand, > > but since I managed to get around it, no need to bother this list further. > > Sorry about the noise. > > Nowadays we also support --include and --exclude options in "svnadmin dump" > > itself which avoids having to pass the dump stream through svndumpfilter. > > I don't know if this would have prevented your mergeinfo-related problem. > > But I wanted to mention this in case you would like to try it out. > > Or just keep it in mind in case you run into such a problem again. > > In general, the built-in --include and --exclude options can be smarter > > because they have access to context information while the dump stream > > is being created. Whereas svndumpfilter can only obtain information from > > the generated dump stream. > > $ svnadmin help dump > > [...] > > Using --exclude or --include gives results equivalent to authz-based > > path exclusions. In particular, when the source of a copy is > > excluded, the copy is transformed into an add (unlike in 'svndumpfilter'). > > Valid options: > > [...] > > --exclude ARG : filter out nodes with given prefix(es) from dump > > --include ARG : filter out nodes without given prefix(es) from dump > > [...]