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
>
> [...]

Reply via email to