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, Seb
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 the
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.
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
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
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
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?
>
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
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, especial
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
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 entir
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 prefi
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
>> argumen
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.
14 matches
Mail list logo