Re: svn::auto-props and svn:needs-lock

[Justin MASSIOT | Zentek]

Hi Sebastian,

As far as I've understood, since Subversion 1.8 the property
"svn:auto-props" is automatically inherited.
Have you tried to overcharge the property at the node you want a variation?
Not sure but it might take precedence...

Justin MASSIOT  |  Zentek


On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer <
sebastian.weilham...@madheadgames.com> wrote:

> Hello,
>
> I'm having trouble with these features.
>
> I have a folder on which I have set svn:auto-props to *=svn:needs-lock=*.
> I have another folder within this folder for which I would like anything
> inside to not require locks.
>
> It seems, I have no way of removing auto setting the needs lock
> property on newly added files?
>
> This makes sense I guess, considering svn:needs-lock doesn't require a
> value, just needs to be set.
> Feels like the needs-lock requiring either 0 or 1 as a value would make
> this customizable?
>
> Am I correct in my assumption? Or is there a way of handling this specific
> scenario gracefully?
>
> Best,
>
> Sebastian
>
>
>

Svn checkout has no output in the docker image of Ubuntu 22.04

[Jack Chen]

I ran the following command, it seems to be stuck, neither error nor
success：

> docker run --rm ubuntu:22.04 /bin/bash -c "apt-get update && apt-get
> install -y subversion && svn co
> https://github.com/GPUOpen-LibrariesAndSDKs/AMF/trunk/amf/public/include
> --non-interactive amf-headers"

Is there something wrong with my operation?

OS version: ubuntu-20.04
Docker image: official image ubuntu:22.04
svn version: 1.14.1 (r1886195)
2021-12-09T06:54:42.9899234Z Unable to find image 'ubuntu:22.04' locally
2021-12-09T06:54:43.2751566Z 22.04: Pulling from library/ubuntu
2021-12-09T06:54:43.3402611Z aee1767db0dd: Pulling fs layer
2021-12-09T06:54:43.6226622Z aee1767db0dd: Verifying Checksum
2021-12-09T06:54:43.6228068Z aee1767db0dd: Download complete
2021-12-09T06:54:44.6071501Z aee1767db0dd: Pull complete
2021-12-09T06:54:44.6122193Z Digest: 
sha256:f154feaf13b51d16e2b4b5575d69abc808da40c4b80e3a5055aaa4bcc5099d5b
2021-12-09T06:54:44.6151911Z Status: Downloaded newer image for ubuntu:22.04
2021-12-09T06:54:45.4818090Z Get:1 http://security.ubuntu.com/ubuntu 
jammy-security InRelease [90.7 kB]
2021-12-09T06:54:45.6849902Z Get:2 http://archive.ubuntu.com/ubuntu jammy 
InRelease [270 kB]
2021-12-09T06:54:46.1079315Z Get:3 http://archive.ubuntu.com/ubuntu 
jammy-updates InRelease [90.7 kB]
2021-12-09T06:54:46.2061618Z Get:4 http://archive.ubuntu.com/ubuntu 
jammy-backports InRelease [90.7 kB]
2021-12-09T06:54:46.3193095Z Get:5 http://archive.ubuntu.com/ubuntu 
jammy/universe amd64 Packages [17.0 MB]
2021-12-09T06:54:46.9853590Z Get:6 http://archive.ubuntu.com/ubuntu 
jammy/multiverse amd64 Packages [267 kB]
2021-12-09T06:54:46.9879625Z Get:7 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 Packages [1795 kB]
2021-12-09T06:54:47.0191690Z Get:8 http://archive.ubuntu.com/ubuntu 
jammy/restricted amd64 Packages [120 kB]
2021-12-09T06:54:47.8877387Z Fetched 19.7 MB in 2s (8080 kB/s)
2021-12-09T06:54:48.4864291Z Reading package lists...
2021-12-09T06:54:49.1215490Z Reading package lists...
2021-12-09T06:54:49.2798314Z Building dependency tree...
2021-12-09T06:54:49.2800067Z Reading state information...
2021-12-09T06:54:49.4037641Z The following additional packages will be 
installed:
2021-12-09T06:54:49.4040011Z   libapr1 libaprutil1 libexpat1 libgdbm6 
libsasl2-2 libsasl2-modules
2021-12-09T06:54:49.4064144Z   libsasl2-modules-db libserf-1-1 libsqlite3-0 
libssl3 libsvn1 libutf8proc2
2021-12-09T06:54:49.4065003Z Suggested packages:
2021-12-09T06:54:49.4066187Z   gdbm-l10n libsasl2-modules-gssapi-mit | 
libsasl2-modules-gssapi-heimdal
2021-12-09T06:54:49.4067823Z   libsasl2-modules-ldap libsasl2-modules-otp 
libsasl2-modules-sql db5.3-util
2021-12-09T06:54:49.4069628Z   libapache2-mod-svn patch subversion-tools
2021-12-09T06:54:49.4701124Z The following NEW packages will be installed:
2021-12-09T06:54:49.4703559Z   libapr1 libaprutil1 libexpat1 libgdbm6 
libsasl2-2 libsasl2-modules
2021-12-09T06:54:49.4707829Z   libsasl2-modules-db libserf-1-1 libsqlite3-0 
libssl3 libsvn1 libutf8proc2
2021-12-09T06:54:49.4708648Z   subversion
2021-12-09T06:54:49.6672363Z 0 upgraded, 13 newly installed, 0 to remove and 21 
not upgraded.
2021-12-09T06:54:49.6673996Z Need to get 5206 kB of archives.
2021-12-09T06:54:49.6674978Z After this operation, 19.1 MB of additional disk 
space will be used.
2021-12-09T06:54:49.6676839Z Get:1 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libssl3 amd64 3.0.0-1ubuntu1 [1896 kB]
2021-12-09T06:54:50.4898908Z Get:2 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libexpat1 amd64 2.4.1-3 [90.1 kB]
2021-12-09T06:54:50.4900487Z Get:3 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libsqlite3-0 amd64 3.36.0-2 [641 kB]
2021-12-09T06:54:50.4901848Z Get:4 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libgdbm6 amd64 1.22-1 [35.2 kB]
2021-12-09T06:54:50.4903627Z Get:5 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libapr1 amd64 1.7.0-6ubuntu1 [107 kB]
2021-12-09T06:54:50.4905675Z Get:6 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libaprutil1 amd64 1.6.1-5ubuntu3 [92.5 kB]
2021-12-09T06:54:50.4907689Z Get:7 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libsasl2-modules-db amd64 2.1.27+dfsg2-2build1 [20.6 kB]
2021-12-09T06:54:50.4909481Z Get:8 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libsasl2-2 amd64 2.1.27+dfsg2-2build1 [53.9 kB]
2021-12-09T06:54:50.4911057Z Get:9 http://archive.ubuntu.com/ubuntu jammy/main 
amd64 libsasl2-modules amd64 2.1.27+dfsg2-2build1 [57.3 kB]
2021-12-09T06:54:50.4912782Z Get:10 http://archive.ubuntu.com/ubuntu 
jammy/universe amd64 libserf-1-1 amd64 1.3.9-10ubuntu1 [49.8 kB]
2021-12-09T06:54:50.4914306Z Get:11 http://archive.ubuntu.com/ubuntu 
jammy/universe amd64 libutf8proc2 amd64 2.5.0-1 [50.0 kB]
2021-12-09T06:54:50.4916487Z Get:12 http://archive.ubuntu.com/ubuntu 
jammy/universe amd64 libsvn1 amd64 1.14.1-3 [1276 kB]
2021-12-09T06:54:50.5184906Z Get:13 http://archive.ubuntu.com/ubuntu 
jammy/universe amd64 subversion amd64 1.14.1-3 [836 kB]
2021

Re: Svn checkout has no output in the docker image of Ubuntu 22.04

[Thorsten]

Hello,

You DO get the output of apt right? I was able to reproduce the problem 
and it seems like its a github/ubuntu-docker certificate thingy. Maybe a 
security expert can tell us more. As  workaround using an older version 
of ubuntu and ignoring certifactes works.


docker run --rm ubuntu:20.04 /bin/bash -c "apt-get update && apt-get 
install -y subversion && svn co 
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/trunk/amf/public/include 
--trust-server-cert --non-interactive amf-headers"



Best regards,

Thorsten


Am 09/12/2021 um 08:16 schrieb Jack Chen:
I ran the following command, it seems to be stuck, neither error nor 
success：


docker run --rm ubuntu:22.04 /bin/bash -c "apt-get update &&
apt-get install -y subversion && svn co
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/trunk/amf/public/include
--non-interactive amf-headers"

Is there something wrong with my operation?

OS version: ubuntu-20.04
Docker image: official image ubuntu:22.04
svn version: 1.14.1 (r1886195)

Re: svn::auto-props and svn:needs-lock

[Sebastian Weilhammer]

Hello Justin,

So that's the thing, I cannot seem to remove the svn:needs-lock from
svn:auto-props for the node in question and I can't change it's value in
such a way where it will stop adding svn:needs-lock to newly added files.
If that's what you mean by overcharge?

Essentially setting svn:auto-props to *=, *=svn:needs-lock= or
*=svn:needs-lock does not get this to work.

On Thu, Dec 9, 2021 at 9:18 AM Justin MASSIOT | Zentek <
justin.mass...@zentek.fr> wrote:

> Hi Sebastian,
>
> As far as I've understood, since Subversion 1.8 the property
> "svn:auto-props" is automatically inherited.
> Have you tried to overcharge the property at the node you want
> a variation? Not sure but it might take precedence...
>
> Justin MASSIOT  |  Zentek
>
>
> On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer <
> sebastian.weilham...@madheadgames.com> wrote:
>
>> Hello,
>>
>> I'm having trouble with these features.
>>
>> I have a folder on which I have set svn:auto-props to *=svn:needs-lock=*.
>> I have another folder within this folder for which I would like anything
>> inside to not require locks.
>>
>> It seems, I have no way of removing auto setting the needs lock
>> property on newly added files?
>>
>> This makes sense I guess, considering svn:needs-lock doesn't require a
>> value, just needs to be set.
>> Feels like the needs-lock requiring either 0 or 1 as a value would make
>> this customizable?
>>
>> Am I correct in my assumption? Or is there a way of handling this
>> specific scenario gracefully?
>>
>> Best,
>>
>> Sebastian
>>
>>
>>
>

-- 

*Sebastian Weilhammer*

Technical Director

madheadgames.com 

Re: svn::auto-props and svn:needs-lock

[Justin MASSIOT | Zentek]

By overcharge I meant "define a new property with a value which differs
from the one that is inherited", either for svn:auto-props or
svn:needs-lock.
I'm really not sure it would work, but it's worth the try.

Justin MASSIOT  |  Zentek


On Thu, 9 Dec 2021 at 10:43, Sebastian Weilhammer <
sebastian.weilham...@madheadgames.com> wrote:

> Hello Justin,
>
> So that's the thing, I cannot seem to remove the svn:needs-lock from
> svn:auto-props for the node in question and I can't change it's value in
> such a way where it will stop adding svn:needs-lock to newly added files.
> If that's what you mean by overcharge?
>
> Essentially setting svn:auto-props to *=, *=svn:needs-lock= or
> *=svn:needs-lock does not get this to work.
>
> On Thu, Dec 9, 2021 at 9:18 AM Justin MASSIOT | Zentek <
> justin.mass...@zentek.fr> wrote:
>
>> Hi Sebastian,
>>
>> As far as I've understood, since Subversion 1.8 the property
>> "svn:auto-props" is automatically inherited.
>> Have you tried to overcharge the property at the node you want
>> a variation? Not sure but it might take precedence...
>>
>> Justin MASSIOT  |  Zentek
>>
>>
>> On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer <
>> sebastian.weilham...@madheadgames.com> wrote:
>>
>>> Hello,
>>>
>>> I'm having trouble with these features.
>>>
>>> I have a folder on which I have set svn:auto-props to *=svn:needs-lock=*.
>>> I have another folder within this folder for which I would like anything
>>> inside to not require locks.
>>>
>>> It seems, I have no way of removing auto setting the needs lock
>>> property on newly added files?
>>>
>>> This makes sense I guess, considering svn:needs-lock doesn't require a
>>> value, just needs to be set.
>>> Feels like the needs-lock requiring either 0 or 1 as a value would make
>>> this customizable?
>>>
>>> Am I correct in my assumption? Or is there a way of handling this
>>> specific scenario gracefully?
>>>
>>> Best,
>>>
>>> Sebastian
>>>
>>>
>>>
>>
>
> --
>
> *Sebastian Weilhammer*
>
> Technical Director
>
> madheadgames.com 
>
> 
> 
> 
> 
>

Re: svn::auto-props and svn:needs-lock

[Sebastian Weilhammer]

Is that not what I'm doing by setting svn:auto-props to *= on the child
node?

On Thu, Dec 9, 2021 at 10:46 AM Justin MASSIOT | Zentek <
justin.mass...@zentek.fr> wrote:

> By overcharge I meant "define a new property with a value which differs
> from the one that is inherited", either for svn:auto-props or
> svn:needs-lock.
> I'm really not sure it would work, but it's worth the try.
>
> Justin MASSIOT  |  Zentek
>
>
> On Thu, 9 Dec 2021 at 10:43, Sebastian Weilhammer <
> sebastian.weilham...@madheadgames.com> wrote:
>
>> Hello Justin,
>>
>> So that's the thing, I cannot seem to remove the svn:needs-lock from
>> svn:auto-props for the node in question and I can't change it's value in
>> such a way where it will stop adding svn:needs-lock to newly added files.
>> If that's what you mean by overcharge?
>>
>> Essentially setting svn:auto-props to *=, *=svn:needs-lock= or
>> *=svn:needs-lock does not get this to work.
>>
>> On Thu, Dec 9, 2021 at 9:18 AM Justin MASSIOT | Zentek <
>> justin.mass...@zentek.fr> wrote:
>>
>>> Hi Sebastian,
>>>
>>> As far as I've understood, since Subversion 1.8 the property
>>> "svn:auto-props" is automatically inherited.
>>> Have you tried to overcharge the property at the node you want
>>> a variation? Not sure but it might take precedence...
>>>
>>> Justin MASSIOT  |  Zentek
>>>
>>>
>>> On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer <
>>> sebastian.weilham...@madheadgames.com> wrote:
>>>
 Hello,

 I'm having trouble with these features.

 I have a folder on which I have set svn:auto-props to
 *=svn:needs-lock=*.
 I have another folder within this folder for which I would like
 anything inside to not require locks.

 It seems, I have no way of removing auto setting the needs lock
 property on newly added files?

 This makes sense I guess, considering svn:needs-lock doesn't require a
 value, just needs to be set.
 Feels like the needs-lock requiring either 0 or 1 as a value would make
 this customizable?

 Am I correct in my assumption? Or is there a way of handling this
 specific scenario gracefully?

 Best,

 Sebastian



>>>
>>
>> --
>>
>> *Sebastian Weilhammer*
>>
>> Technical Director
>>
>> madheadgames.com 
>>
>> 
>> 
>> 
>> 
>>
>

-- 

*Sebastian Weilhammer*

Technical Director

madheadgames.com 

Re: svn::auto-props and svn:needs-lock

[Justin MASSIOT | Zentek]

Not if the needs-lock attribute is also set by a "svn:auto-props" property,
I suppose.

Justin MASSIOT  |  Zentek


On Thu, 9 Dec 2021 at 11:18, Sebastian Weilhammer <
sebastian.weilham...@madheadgames.com> wrote:

> Is that not what I'm doing by setting svn:auto-props to *= on the child
> node?
>
> On Thu, Dec 9, 2021 at 10:46 AM Justin MASSIOT | Zentek <
> justin.mass...@zentek.fr> wrote:
>
>> By overcharge I meant "define a new property with a value which differs
>> from the one that is inherited", either for svn:auto-props or
>> svn:needs-lock.
>> I'm really not sure it would work, but it's worth the try.
>>
>> Justin MASSIOT  |  Zentek
>>
>>
>> On Thu, 9 Dec 2021 at 10:43, Sebastian Weilhammer <
>> sebastian.weilham...@madheadgames.com> wrote:
>>
>>> Hello Justin,
>>>
>>> So that's the thing, I cannot seem to remove the svn:needs-lock from
>>> svn:auto-props for the node in question and I can't change it's value in
>>> such a way where it will stop adding svn:needs-lock to newly added files.
>>> If that's what you mean by overcharge?
>>>
>>> Essentially setting svn:auto-props to *=, *=svn:needs-lock= or
>>> *=svn:needs-lock does not get this to work.
>>>
>>> On Thu, Dec 9, 2021 at 9:18 AM Justin MASSIOT | Zentek <
>>> justin.mass...@zentek.fr> wrote:
>>>
 Hi Sebastian,

 As far as I've understood, since Subversion 1.8 the property
 "svn:auto-props" is automatically inherited.
 Have you tried to overcharge the property at the node you want
 a variation? Not sure but it might take precedence...

 Justin MASSIOT  |  Zentek


 On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer <
 sebastian.weilham...@madheadgames.com> wrote:

> Hello,
>
> I'm having trouble with these features.
>
> I have a folder on which I have set svn:auto-props to
> *=svn:needs-lock=*.
> I have another folder within this folder for which I would like
> anything inside to not require locks.
>
> It seems, I have no way of removing auto setting the needs lock
> property on newly added files?
>
> This makes sense I guess, considering svn:needs-lock doesn't require a
> value, just needs to be set.
> Feels like the needs-lock requiring either 0 or 1 as a value would
> make this customizable?
>
> Am I correct in my assumption? Or is there a way of handling this
> specific scenario gracefully?
>
> Best,
>
> Sebastian
>
>
>

>>>
>>> --
>>>
>>> *Sebastian Weilhammer*
>>>
>>> Technical Director
>>>
>>> madheadgames.com 
>>>
>>> 
>>> 
>>> 
>>> 
>>>
>>
>
> --
>
> *Sebastian Weilhammer*
>
> Technical Director
>
> madheadgames.com 
>
> 
> 
> 
> 
>

svndumpfilter: finding source commit for error?

[Kristofer]

Hi,

I'm doing some work on an old, bloated repo to get rid of some erroneous 
commits to reduce the disk size. I've done this a few years ago with success, 
but I'm currently getting into an error situation that I don't know how to 
handle.

I'm running something like
"svadmin dump | svndumpfilter "

This works fine until I get to
Committing revision 10 as 10
svndumpfilter: E23: Missing merge source path 
'project/branches/somebranch/idioticdir-i-will-filter'; try with 
--skip-missing-merge-sources

I do understand what the message means, but I cannot for the life of me figure 
out which commit it is that is causing the problem. I do not want to skip the 
merge source, I want to add the place it has been copied to into the filterfile.

Revision 10 has nothing to do with that branch and neither has 11, so 
I'm guessing a that is a stderr/stdout type of mismatch in the printouts and 
the error happens later than 10. I first tried to see that nothing is done 
on that specific branch that I am looking at and nope, that branch is 
"finished" at this point.
Then I have tried to look 200 revisions into the future to see if I can find a 
copy operation (basically do diff --summarize and grep for 
"idioticdir-i-will-filter") and I can't find it there either).
Tried playing around with svnlook and I fail there as well, but I'm not really 
used to this one and might be missing some nice option. I am running out of 
ideas how to find the new place it is copied to and add it to my filterfile.
Note: I cannot have a globbing filter on the name of the directory since that 
appears as a valid part of the project in many other places.

Any ideas why it is not printing both source and target of the copy, which is 
what I have seen other times with "copy source error"?
Any ideas on how to find the commit that is eluding me will be greatly 
appreciated.

Note: using svn 1.14

Re: svndumpfilter: finding source commit for error?

[Kristofer]

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.

‐‐‐ Original Message ‐‐‐
On Thursday, December 9th, 2021 at 4:44 PM, Kristofer 
 wrote:

> Hi,
>
> I'm doing some work on an old, bloated repo to get rid of some erroneous 
> commits to reduce the disk size. I've done this a few years ago with success, 
> but I'm currently getting into an error situation that I don't know how to 
> handle.
>
> I'm running something like
> "svadmin dump | svndumpfilter "
>
> This works fine until I get to
> Committing revision 10 as 10
> svndumpfilter: E23: Missing merge source path 
> 'project/branches/somebranch/idioticdir-i-will-filter'; try with 
> --skip-missing-merge-sources
>
> I do understand what the message means, but I cannot for the life of me 
> figure out which commit it is that is causing the problem. I do not want to 
> skip the merge source, I want to add the place it has been copied to into the 
> filterfile.
>
> Revision 10 has nothing to do with that branch and neither has 11, so 
> I'm guessing a that is a stderr/stdout type of mismatch in the printouts and 
> the error happens later than 10. I first tried to see that nothing is 
> done on that specific branch that I am looking at and nope, that branch is 
> "finished" at this point.
> Then I have tried to look 200 revisions into the future to see if I can find 
> a copy operation (basically do diff --summarize and grep for 
> "idioticdir-i-will-filter") and I can't find it there either).
> Tried playing around with svnlook and I fail there as well, but I'm not 
> really used to this one and might be missing some nice option. I am running 
> out of ideas how to find the new place it is copied to and add it to my 
> filterfile.
> Note: I cannot have a globbing filter on the name of the directory since that 
> appears as a valid part of the project in many other places.
>
> Any ideas why it is not printing both source and target of the copy, which is 
> what I have seen other times with "copy source error"?
> Any ideas on how to find the commit that is eluding me will be greatly 
> appreciated.
>
> Note: using svn 1.14

Re: svndumpfilter: finding source commit for error?

[Stefan Sperling]

On Thu, Dec 09, 2021 at 05:07:09PM +, 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
[...]

Re: svndumpfilter: finding source commit for error?

[Kristofer]

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  
wrote:

> On Thu, Dec 09, 2021 at 05:07:09PM +, 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
>
> [...]

Re: svndumpfilter: finding source commit for error?

[Stefan Sperling]

On Thu, Dec 09, 2021 at 06:29:14PM +, 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.

Re: svndumpfilter: finding source commit for error?

[Luke Mauldin]

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  wrote:
> 
> On Thu, Dec 09, 2021 at 06:29:14PM +, 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.

Re: svndumpfilter: finding source commit for error?

[Stefan Sperling]

On Thu, Dec 09, 2021 at 01:04:24PM -0600, Luke Mauldin wrote:
> Did this problematic commit occur due to a bug at the time in Subversion or a 
> user error?
> 
> Luke

The log message suggests it was a deliberate choice, and there was
some discussion about it after the fact.
See https://svn.apache.org/r1295006 and 
https://marc.info/?t=13986609788&r=1&w=2

Anyway, since this code lives in the ASF repository there was nothing
that could be done to undo the copy without impacting every ASF project.