subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davor Josipovic <>
Subject Re: Reference to non-existent node
Date Tue, 20 Feb 2018 16:26:22 GMT
> 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 were transaction 463-e1 up to 463-e9...) the MERGE would sometimes
show before the DELETE in the error log. That is what let me believe that MERGE error was
primary, then the DELETE error (even though it seems the other way around in the apache2 log).

> What sort of filesystem hosts the repository?

The filesystem for the reported transaction 463-e8 is EXT4 (noatime, nodiratime, data=ordered).
Prior to that, the repository was on a NTFS formatted drive. The error was the same, but since
I thought NTFS was the culprit, I moved to EXT4.

I have also tried with a older client (1.8, cf. stakoverflow question edit history), but the
error was the same serverside (and slightly different clientside).

Since then I had some 20 commits. No issues...

On 20 February 2018 at 13:09, Philip Martin <<>>
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:61712] An error occurred while committing the transaction.  [500,
>> #160014]
>>     [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client
>> X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in
>> filesystem '/mnt/vc/svn/repo/db'  [500, #160014]
>> The client side gives:
>>     done
>>     Committing transaction...
>>     svn: E175012: Commit failed (details follow):
>>     svn: E175012: Connection timed out
>>     svn: E200042: Additional errors:
>>     svn: E175002: Unexpected server error 500 'Internal Server Error' on
>> '/svn/repo/!svn/txn/463-e8'
>> First I thought this was a permission issue. So I did this on the server:
>>     su - www-data -s /bin/bash -c "svnadmin rmtxns /mnt/vc/svn/repo/ 463-e8"
>>     Transaction '463-e8' removed.
>> No error whatsoever. Apache runs as `www-data`. Following permissions are
>> set:
>>     chown www-data:www-data /mnt/vc -R
>>     chmod 0774 /mnt/vc -R

The server error suggests that at least one of the files that make up
the transaction is missing from disk when the MERGE is attempted.
That's odd, it is not a commonly seen error.

Even more odd is that you show "svnadmin rmtxns" succeeding.  This is
odd, very odd, because when a MERGE fails the server code in mod_dav_svn
reacts by removing the transaction from disk.  In addition, when the
client gets the failed MERGE repsonse it also reacts and sends a DELETE
to remove the transaction from disk; this DELETE usually fails with 404:

 [dav:error] [pid 13161:tid 140441001391872] [client ::1:44218] Could not fetch resource information.
 [404, #0]
 [dav:error] [pid 13161:tid 140441001391872] [client ::1:44218] Named transaction doesn't
exist.  [404, #175002]

Do you see the DELETE in the log after the failed MERGE?  Was there an

After a failed MERGE an attempt to run "svnadmin rmtxns" manually would
normally fail with:

 E160007: No such transaction '463-e8'

but your attempt succeeded so at least some of the transaction was
present on disk.

So it looks like several strange things have happened:

 - one of the files on disk that make up the transaction is missing
   causing the MERGE to fail

 - both automatic attempts to delete the transaction on disk have failed
   causing the transaction to persist on disk

 - whatever caused the transaction to persist on disk doesn't prevent
   "svnadmin rmtxns" from working

The "_1bqk" implies that this transaction affects over 60,000 nodes,
this is large but Subversion should handle it.

What sort of filesystem hosts the repository?


View raw message