On Tue, May 22, 2018 at 8:30 PM, Davor Josipovic wrote:
>> Now that is interesting. 40k doesn't seem to be such a large amount of
>> data for modern computers. Very slow and fragmented hard drive? Or perhaps
>> there's something else going on that is manifesting this way?
>
> The HDD is indeed on
On Tue, May 22, 2018 at 2:36 PM Davor Josipovic wrote:
> > Now that is interesting. 40k doesn't seem to be such a large amount of
data for modern computers. Very slow and fragmented hard drive? Or perhaps
there's something else going on that is manifesting this way?
> The HDD is indeed on the s
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
> Now that is interesting. 40k doesn't seem to be such a large amount of data
> for modern computers. Very slow and fragmented hard drive? Or perhaps there's
> something else going on that is manifesting this way?
The HDD is indeed on the slowside, and together with low memory...
But I think t
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
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
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
Davor Josipovic writes:
> You make the PID sound very important, and with good reason too! I
> just went back through the logs to make sure that I didn't mess up the
> PID before posting. I didn't. In each case, the PID was
> different. This might explain the time difference.
The Subversion clie
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later w
Davor Josipovic writes:
>> Are you running Linux or Windows? Is the disk local or networked?
>
> Server is Debian 9.3. Disk is mounted through fstab with options
> noatime,nodiratime,data=ordered,nofail.
>
>> Do you have some other process running that mointors the filesystem or
>> the repositor
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options
noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
Davor Josipovic writes:
>> Do you see the DELETE in the log after the failed MERGE? Was there an
>> error?
>
> The apache2 log I posted is the whole log for that day as far as I
> recall. There was nothing else. You see the DELETE error before the
> MERGE error. I think that is due to a timing i
> Do you see the DELETE in the log after the failed MERGE? Was there an
> error?
The apache2 log I posted is the whole log for that day as far as I recall.
There was nothing else. You see the DELETE error before the MERGE error. I
think that is due to a timing issue. In my previous tries (there
> Do you see the DELETE in the log after the failed MERGE? Was there an
> error?
The apache2 log I posted is the whole log for that day as far as I recall.
There was nothing else. You see the DELETE error before the MERGE error. I
think that is due to a timing issue. In my previous tries (there
> Do you see the DELETE in the log after the failed MERGE? Was there an
> error?
The apache2 log I posted is the whole log for that day as far as I recall.
There was nothing else. You see the DELETE error before the MERGE error. I
think that is due to a timing issue. In my previous tries (there
Johan Corveleyn writes:
>> [Sat Feb 10 03:25:30.640591 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Could not MERGE resource "/svn/repo/!svn/txn/463-e8" into
>> "/svn/repo/repofolder". [500, #0]
>> [Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:6171
On Sun, Feb 18, 2018 at 9:58 PM, Davor Josipovic wrote:
> Here you go (copy from the link):
>
>
>
> Can someone help me debug this issue? Everything works (i.e. I can commit
Here you go (copy from the link):
Can someone help me debug this issue? Everything works (i.e. I can commit,
checkout, etc.) but this one commit always fails as described
Here you go (copy from the link):
Can someone help me debug this issue? Everything works (i.e. I can commit,
checkout, etc.) but this one commit always fails as described
On Mon, Feb 12, 2018 at 8:41 AM, Davor Josipovic wrote:
> It seems to me there is a bug in libapache2-mod-svn/stable,stable,now
> 1.9.5-1+deb9u1 amd64 [installed].
>
> I described it
> here:https://superuser.com/questions/1293699/svn-error-occurred-while-committing-the-transaction
>
> I assume thi
27 matches
Mail list logo
