svn up -r {DATE} returns E1000104

[Mun Johl]

Hi all,

 

Let me start out by saying I know we are on an old version of SVN on RHEL7, and I apologize in advance for that fact.  Our SVN revision is: v1.9.12

 

We had to obsolete our old local SVN server and then we moved to a remote VM running the aforementioned version of SVN.  Our old local SVN server was running v1.9.3 .  We were trying to keep the SVN revision on the new server close to what we were running in the past to try and avoid any disruptions.

 

Just about everything on the new SVN server works fine, except for: ‘svn up -r {DATE}’.  That command returns the following output:

Updating '.':

svn: E000104: Can't read from connection: Connection reset by peer

 

Note that ‘svn up’ and ‘svn up -rNUMBER’ work just fine.

 

Any insights would be greatly appreciated.

 

Regards,

 

--

Mun

[Daniel Sahlberg]

Den mån 12 juni 2023 kl 20:45 skrev Mun Johl <Mun....@wdc.com>:

Hi all,

 

Let me start out by saying I know we are on an old version of SVN on RHEL7, and I apologize in advance for that fact.  Our SVN revision is: v1.9.12

 

We had to obsolete our old local SVN server and then we moved to a remote VM running the aforementioned version of SVN.  Our old local SVN server was running v1.9.3 .  We were trying to keep the SVN revision on the new server close to what we were running in the past to try and avoid any disruptions.

You should be able to update to any later server version without any problem. Older clients might not be able to use all the features of the new server but there should be cross compatibility with all versions.

 

Just about everything on the new SVN server works fine, except for: ‘svn up -r {DATE}’.  That command returns the following output:

Updating '.':

svn: E000104: Can't read from connection: Connection reset by peer

Which protocol do you use for accessing the repository? (svn info --show-item url should give the url, the protocol is the first part)

Do you see anything in the server log files?

Is it a large repository and could it by any chance be a network issue, where the network connection times out while Subversion is trying to find the revision number corresponding with the date?

Kind regards,

Daniel Sahlberg

[Mun Johl]

Hi Daniel,

 

Thank you very much for your reply.  Please see my comments below.

 

Hi all,

 

Let me start out by saying I know we are on an old version of SVN on RHEL7, and I apologize in advance for that fact.  Our SVN revision is: v1.9.12

 

We had to obsolete our old local SVN server and then we moved to a remote VM running the aforementioned version of SVN.  Our old local SVN server was running v1.9.3 .  We were trying to keep the SVN revision on the new server close to what we were running in the past to try and avoid any disruptions.

 

You should be able to update to any later server version without any problem. Older clients might not be able to use all the features of the new server but there should be cross compatibility with all versions.

 

[Mun] That’s good to know.

 

Just about everything on the new SVN server works fine, except for: ‘svn up -r {DATE}’.  That command returns the following output:

Updating '.':

svn: E000104: Can't read from connection: Connection reset by peer

 

Which protocol do you use for accessing the repository? (svn info --show-item url should give the url, the protocol is the first part)

 

[Mun] svn:

 

Do you see anything in the server log files?

 

[Mun] Our Linux Administrator stated he didn’t see anything pertinent in the server logs.  Is there any way to increase verbosity or something so as to log debug information?

 

Is it a large repository and could it by any chance be a network issue, where the network connection times out while Subversion is trying to find the revision number corresponding with the date?

 

[Mun] I wouldn’t necessarily consider it a large repository—but it’s not small either.  Your network issue concern is interesting since the server is now at a different corporate site.  However, empirically I would have expected that perhaps the issue would be intermittent if it were a network issue.  This problem occurs every time I’ve tried the command—even at different times of the day.  Not that that proves anything—it’s just meant to be a data point.

 

I’ve tried the command in a branch that isn’t very large—but maybe that doesn’t make a difference if it’s the total repository size that makes a difference—and I still had the same issue with ‘svn up -r {DATE}’.

 

Thank you very much for your feedback!

 

Best regards,

 

--

Mun Johl

 

Kind regards,

Daniel Sahlberg

[Daniel Sahlberg]

Den tis 13 juni 2023 kl 17:33 skrev Mun Johl <Mun....@wdc.com>:

[... snip ...]

Which protocol do you use for accessing the repository? (svn info --show-item url should give the url, the protocol is the first part)

 

[Mun] svn:

Thanks for checking! Then we need to look at svnserve.

Can you figure out how it is started? It can be run either in daemon mode (starting as a standalone daemon using the -d | --daemon argument) or started from [x]inetd (using the -i | --inetd argument).

Do you see anything in the server log files?

 

[Mun] Our Linux Administrator stated he didn’t see anything pertinent in the server logs.  Is there any way to increase verbosity or something so as to log debug information?

I haven't used svnserve myself in production so I'm a little bit in the dark here, but if I'm reading the code correctly you need to add the --log-file FILENAME argument when you start svnserve. How to do this depends on if you run the service as a daemon or from x[inetd], and also depends on your Linux distribution.

Is it a large repository and could it by any chance be a network issue, where the network connection times out while Subversion is trying to find the revision number corresponding with the date?

 

[Mun] I wouldn’t necessarily consider it a large repository—but it’s not small either.  Your network issue concern is interesting since the server is now at a different corporate site.  However, empirically I would have expected that perhaps the issue would be intermittent if it were a network issue.  This problem occurs every time I’ve tried the command—even at different times of the day.  Not that that proves anything—it’s just meant to be a data point.

 

I’ve tried the command in a branch that isn’t very large—but maybe that doesn’t make a difference if it’s the total repository size that makes a difference—and I still had the same issue with ‘svn up -r {DATE}’.

These are valid points. There could still be a network issue, for example a package inspecting firewall that trigger on something when you run svn up -r {DATE}, but I agree this seems unlikely. Still, to rule out network issues, can you try the same command on the svn server itself or at least from a computer on the same site/network? If you don't have access, maybe the Linux admins can help you out.

Kind regards,

Daniel Sahlberg

[Mun Johl]

Hi Daniel,

 

[... snip ...]

Which protocol do you use for accessing the repository? (svn info --show-item url should give the url, the protocol is the first part)

 

[Mun] svn:

 

Thanks for checking! Then we need to look at svnserve.

 

Can you figure out how it is started? It can be run either in daemon mode (starting as a standalone daemon using the -d | --daemon argument) or started from [x]inetd (using the -i | --inetd argument).

 

[Mun] Our system admin said he manually starts the server after a reboot using the following command: svnserve -d -r /SVN/RSVL/repos

 

Do you see anything in the server log files?

 

[Mun] Our Linux Administrator stated he didn’t see anything pertinent in the server logs.  Is there any way to increase verbosity or something so as to log debug information?

I haven't used svnserve myself in production so I'm a little bit in the dark here, but if I'm reading the code correctly you need to add the --log-file FILENAME argument when you start svnserve. How to do this depends on if you run the service as a daemon or from x[inetd], and also depends on your Linux distribution.

 

[Mun] We tried with the logs enabled but there wasn’t any additional information present.

 

Is it a large repository and could it by any chance be a network issue, where the network connection times out while Subversion is trying to find the revision number corresponding with the date?

 

[Mun] I wouldn’t necessarily consider it a large repository—but it’s not small either.  Your network issue concern is interesting since the server is now at a different corporate site.  However, empirically I would have expected that perhaps the issue would be intermittent if it were a network issue.  This problem occurs every time I’ve tried the command—even at different times of the day.  Not that that proves anything—it’s just meant to be a data point.

 

I’ve tried the command in a branch that isn’t very large—but maybe that doesn’t make a difference if it’s the total repository size that makes a difference—and I still had the same issue with ‘svn up -r {DATE}’.

 

These are valid points. There could still be a network issue, for example a package inspecting firewall that trigger on something when you run svn up -r {DATE}, but I agree this seems unlikely. Still, to rule out network issues, can you try the same command on the svn server itself or at least from a computer on the same site/network? If you don't have access, maybe the Linux admins can help you out.

 

[Mun] This was a good thought… I tried it from another computer on the same network and the command worked.  So, it does in fact appear to be some kind of network configuration issue.

 

Thank you very much for the insights and assistance!  I will work with our IT team at this point to try and get to a resolution.

 

Best regards,

 

--

Mun