I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
I have finally found the culprit. By coincidence, I had the same configuration
running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD
one with the described error.
Monitoring the process revealed that af
On Mon, May 21, 2018 at 4:05 PM Davor Josipovic wrote:
> I have finally found the culprit. By coincidence, I had the same
> configuration running on two servers, one backed with a SSD, the other with
> a HDD.
>
> The same commit worked on the SSD-backed server, and always failed on the
> HDD one
On Mon, May 21, 2018 at 4:05 PM Davor Josipovic
wrote:
>>I have finally found the culprit. By coincidence, I had the same
>>configuration running on two servers, one backed with a SSD, the
>>other with a HDD.
>>
>>The same commit worked on the SSD-backed server, and always failed
>>on the HDD
I’m running SVN 1.9.3 (r1718519), on Ubuntu 16-04 with Server version:
Apache/2.4.18 (Ubuntu).
Problem is when a user failed 3 times with his password, the account doesn’t
get locked but it keeps prompting. It looks like it authenticates against every
single file in the path of the repo that use
