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.
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 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
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 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
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
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
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?
>
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
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
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
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.
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
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
14 matches
Mail list logo
