You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alexey Neyman <st...@att.net> on 2013/06/23 21:56:27 UTC
Merge error with SVN 1.8.0
Hi,
I've tried upgrading the client to SVN 1.8, and now see some strange merge errors
while reintegrating the branch. According to
http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
the --reintegrate option is now deprecated, its use is discouraged and SVN should be
able to figure that out automatically. However, when I tried a plain "svn merge", it
gave me the following error:
[aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
svn: E210002: Network connection closed unexpectedly
Strangely, 'svn merge --reintegrate' worked fine.
We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4" version). I
installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the client.
Any clues/suggestions as to how to debug this further?
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 05.07.2013 23:04, Alexey Neyman wrote:
> My point was that the problem is most likely not a *packaging* issue,
> which was confirmed in my next message (the issue is due to 1.8.x
> making more connections from client to server when doing 'svn merge').
That's most likely a side effect of the improved merge behaviour, and
something we probably want to fix in a future release.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Sunday, June 30, 2013 04:33:45 PM Branko Čibej wrote:
> On 24.06.2013 01:38, Alexey Neyman wrote:
> > Are you calling RPMs provided by WanDisco's "fun and games"? I think
> > Subversion developers employed by WanDisco might be somewhat insulted
> > by such judgment.
>
> Hmm .... I'd sooner be insulted by someone anticipating my reaction like
> that. :)
>
> Nobody's perfect. If you find a bug in WANdisco's binary packages, I for
> one would definitely like to know about it.
Sorry for insulting you then :) My point was that the problem is most likely not a
*packaging* issue, which was confirmed in my next message (the issue is due to
1.8.x making more connections from client to server when doing 'svn merge').
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Jun 23, 2013 at 7:38 PM, Alexey Neyman <st...@att.net> wrote:
> On Sunday, June 23, 2013 07:20:50 PM Nico Kadel-Garcia wrote:
>
>> On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman <st...@att.net> wrote:
>
>> > Hi,
>
>> >
>
>> >
>
>> >
>
>> > I've tried upgrading the client to SVN 1.8, and now see some strange
>> > merge
>
>> > errors while reintegrating the branch. According to
>
>>
>
>> Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying
>
>> around and confusing you? Or binaries turning up in your "commit"
>
>> scripts due to inherited "PATH" that does not include the new version?
>
>
>
> Sorry for being unclear: I only upgraded the CLIENT, not the server. The
> server still has 1.6.11. And yes, sorry for stating the obvious, the 1.7.10
> subversion RPM was removed when I installed 1.8.0.
>
>
>
>> To avoid the fun and games, I urge you to grab and test my newly
>> minted Subversion 1.8.0 RPM building tools, at:
>> https://github.com/nkadel/subversion-1.8.x-srpm
>
> Are you calling RPMs provided by WanDisco's "fun and games"? I think
> Subversion developers employed by WanDisco might be somewhat insulted by
> such judgment. Is there something wrong with RPMs from WanDisco that I must,
> in your opinion, switch to your version?
No, no, I missed that you were using WanDisco RPM's. (Not sure how I
missed that, I do sometimes get interrupted doing my email.) I
respect WanDisco's work and had no intent to insult them. And if
you're using WanDisco, I'd seriously consider a commercial contract
with them to take advantage of their multiple-master tools for
mirroring Subversion repositories safely. That would actually help
*fund* Subversion development.
In fact.... If you can, I'd consider making a copy of the repository
to another host and testing it with the Wandisco or another Subversion
1.8.0 *server*, not just client.
>> I've also bundled a libserf SRPM building toolkit at:
>
>> https://github.com/nkadel/libserf-1.2.x-srpm
>
> Thanks. I thought that my original email indicated that we're using svn://
> protocol and thus serf is out of the equation.
It's cool. I'm not suggesting you have to locally build or compile
serf unless you care to build from my SRPM, It's a dependency for
building a full Subversion 1.8.0 toolkit. If you feel like getting
into the code yourself, you'll need something like it.
In fact...... If you like playing with source and working with your own copies,
> In other words: do you have anything relevant to say regarding the reported
> issue, rather than advertising your work?
I made a mistake about the source of your software, and did apologize.
Since it's from Wandisco, and you're jumping to the bleeding edge with
Subvesion 1.8.x on RHEL 6 based operating systems, why not contact
them for commercial support?
Re: Merge error with SVN 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 24.06.2013 01:38, Alexey Neyman wrote:
>
> Are you calling RPMs provided by WanDisco's "fun and games"? I think
> Subversion developers employed by WanDisco might be somewhat insulted
> by such judgment.
>
Hmm .... I'd sooner be insulted by someone anticipating my reaction like
that. :)
Nobody's perfect. If you find a bug in WANdisco's binary packages, I for
one would definitely like to know about it.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Sunday, June 23, 2013 07:20:50 PM Nico Kadel-Garcia wrote:
> On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman <st...@att.net> wrote:
> > Hi,
> >
> >
> >
> > I've tried upgrading the client to SVN 1.8, and now see some strange merge
> > errors while reintegrating the branch. According to
>
> Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying
> around and confusing you? Or binaries turning up in your "commit"
> scripts due to inherited "PATH" that does not include the new version?
Sorry for being unclear: I only upgraded the CLIENT, not the server. The server still has
1.6.11. And yes, sorry for stating the obvious, the 1.7.10 subversion RPM was
removed when I installed 1.8.0.
> To avoid the fun and games, I urge you to grab and test my newly
> minted Subversion 1.8.0 RPM building tools, at:
>
> https://github.com/nkadel/subversion-1.8.x-srpm
Are you calling RPMs provided by WanDisco's "fun and games"? I think Subversion
developers employed by WanDisco might be somewhat insulted by such judgment. Is
there something wrong with RPMs from WanDisco that I must, in your opinion, switch
to your version?
> I've also bundled a libserf SRPM building toolkit at:
>
> https://github.com/nkadel/libserf-1.2.x-srpm
Thanks. I thought that my original email indicated that we're using svn:// protocol and
thus serf is out of the equation.
In other words: do you have anything relevant to say regarding the reported issue,
rather than advertising your work?
Regards,
Alexey.
>
> I've been testing out the 1.8.x features, it's suitable for pushing to
> Rpmforge. EPEL would take a lot more work because there are key
> libraries, like "SQLite", that have to be compiled locally even for
> RHEL 6. And Fedora 19, which is coming out, does not use SysV init
> scripts at all, it uses system, so the "svnserve" init script will be
> rejected out of hand.
>
> > http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
> >
> >
> >
> > the --reintegrate option is now deprecated, its use is discouraged and SVN
> > should be able to figure that out automatically. However, when I tried a
> > plain "svn merge", it gave me the following error:
> >
> >
> >
> > [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
> >
> > svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
> >
> > svn: E210002: Network connection closed unexpectedly
> >
> >
> >
> > Strangely, 'svn merge --reintegrate' worked fine.
> >
> >
> >
> > We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4"
> > version). I installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the
> > client.
> >
> >
> >
> > Any clues/suggestions as to how to debug this further?
> >
> >
> >
> > Regards,
> >
> > Alexey.
Re: Merge error with SVN 1.8.0
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman <st...@att.net> wrote:
> Hi,
>
>
>
> I've tried upgrading the client to SVN 1.8, and now see some strange merge
> errors while reintegrating the branch. According to
Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying
around and confusing you? Or binaries turning up in your "commit"
scripts due to inherited "PATH" that does not include the new version?
To avoid the fun and games, I urge you to grab and test my newly
minted Subversion 1.8.0 RPM building tools, at:
https://github.com/nkadel/subversion-1.8.x-srpm
I've also bundled a libserf SRPM building toolkit at:
https://github.com/nkadel/libserf-1.2.x-srpm
I've been testing out the 1.8.x features, it's suitable for pushing to
Rpmforge. EPEL would take a lot more work because there are key
libraries, like "SQLite", that have to be compiled locally even for
RHEL 6. And Fedora 19, which is coming out, does not use SysV init
scripts at all, it uses system, so the "svnserve" init script will be
rejected out of hand.
>
>
>
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
>
>
>
> the --reintegrate option is now deprecated, its use is discouraged and SVN
> should be able to figure that out automatically. However, when I tried a
> plain "svn merge", it gave me the following error:
>
>
>
> [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
>
> svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
>
> svn: E210002: Network connection closed unexpectedly
>
>
>
> Strangely, 'svn merge --reintegrate' worked fine.
>
>
>
> We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4"
> version). I installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the client.
>
>
>
> Any clues/suggestions as to how to debug this further?
>
>
>
> Regards,
>
> Alexey.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Saturday, June 29, 2013 01:18:16 PM Stefan Sperling wrote:
> On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> > [copying dev@ because I found what the issue is]
> >
> > Hi,
> >
> > Did some further investigation and it turns out that SVN1.8 client creates
> > more connections to the server when performing 'svn merge' - exceeding
> > the xinetd's default number of connections per source (10) and indeed,
> > closing the connection on an unsuspecting client. After increasing the
> > number of connections per source to unlimited, the merge went through.
> >
> > Here are some statistics:
> >
> > SVN 1.7, merge --reintegrate
> > 13 connections total, 5 concurrent connections maximum
> >
> > SVN 1.8, merge
> > 18 connections total, 11 concurrent connections maximum
> >
> > SVN 1.8, merge --reintegrate
> > 5 connections total, 3 concurrent connections maximum
> >
> > So, it looks like the new code for automatic detection of "reintegration
> > merges" in 1.8 spawns a bunch of additional connections. So, the question
> > is - what is the maximum number of connections that a client can create
> > to a server? Does it depend on the size of the change? Size of the
> > svn:mergeinfo?
> >
> > I am not comfortable leaving the server configuration at "unlimited",
> > seeing that xinetd limit is a safety net against runaway client bringing
> > down the server.
> I'm not entirely sure how to estimate the largest number
> of connections made by 'svn merge'.
>
> Note that the number of connections also depends on the amount of
> svn:externals involved in checkouts and updates. One new connection
> is opened for each external.
>
> You might be interested in Ivan's RA session reuse patch:
> http://svn.haxx.se/dev/archive-2013-06/0292.shtml
> http://subversion.tigris.org/issues/show_bug.cgi?id=3763
> This will probably be in 1.9, so it won't help you now. But I still
> thought it was worth mentioning since it will address your problem
> in the long term.
Sorry for a late response. The checked out WC I did a merge in did not have any
externals, but it had 8 svn:mergeinfo entries, if it matters.
I think at the very least this issue needs to be reflected in the "SVN book". Right now,
the section "svnserve via xinetd" does not mention it, nor does the example
configuration specify an unlimited number of connections per source. Given that
xinentd's default is 10 connections per source IP, it is fairly easy to go over that limit.
As to session reuse: am I right that it is going to avoid closing connections and reuse
it instead of opening a new one? In that case, it does not solve an issue with
concurrent connections (as they're still active, they can't be reused).
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Saturday, June 29, 2013 01:18:16 PM Stefan Sperling wrote:
> On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> > [copying dev@ because I found what the issue is]
> >
> > Hi,
> >
> > Did some further investigation and it turns out that SVN1.8 client creates
> > more connections to the server when performing 'svn merge' - exceeding
> > the xinetd's default number of connections per source (10) and indeed,
> > closing the connection on an unsuspecting client. After increasing the
> > number of connections per source to unlimited, the merge went through.
> >
> > Here are some statistics:
> >
> > SVN 1.7, merge --reintegrate
> > 13 connections total, 5 concurrent connections maximum
> >
> > SVN 1.8, merge
> > 18 connections total, 11 concurrent connections maximum
> >
> > SVN 1.8, merge --reintegrate
> > 5 connections total, 3 concurrent connections maximum
> >
> > So, it looks like the new code for automatic detection of "reintegration
> > merges" in 1.8 spawns a bunch of additional connections. So, the question
> > is - what is the maximum number of connections that a client can create
> > to a server? Does it depend on the size of the change? Size of the
> > svn:mergeinfo?
> >
> > I am not comfortable leaving the server configuration at "unlimited",
> > seeing that xinetd limit is a safety net against runaway client bringing
> > down the server.
> I'm not entirely sure how to estimate the largest number
> of connections made by 'svn merge'.
>
> Note that the number of connections also depends on the amount of
> svn:externals involved in checkouts and updates. One new connection
> is opened for each external.
>
> You might be interested in Ivan's RA session reuse patch:
> http://svn.haxx.se/dev/archive-2013-06/0292.shtml
> http://subversion.tigris.org/issues/show_bug.cgi?id=3763
> This will probably be in 1.9, so it won't help you now. But I still
> thought it was worth mentioning since it will address your problem
> in the long term.
Sorry for a late response. The checked out WC I did a merge in did not have any
externals, but it had 8 svn:mergeinfo entries, if it matters.
I think at the very least this issue needs to be reflected in the "SVN book". Right now,
the section "svnserve via xinetd" does not mention it, nor does the example
configuration specify an unlimited number of connections per source. Given that
xinentd's default is 10 connections per source IP, it is fairly easy to go over that limit.
As to session reuse: am I right that it is going to avoid closing connections and reuse
it instead of opening a new one? In that case, it does not solve an issue with
concurrent connections (as they're still active, they can't be reused).
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> [copying dev@ because I found what the issue is]
>
> Hi,
>
> Did some further investigation and it turns out that SVN1.8 client creates more
> connections to the server when performing 'svn merge' - exceeding the xinetd's
> default number of connections per source (10) and indeed, closing the connection on
> an unsuspecting client. After increasing the number of connections per source to
> unlimited, the merge went through.
>
> Here are some statistics:
>
> SVN 1.7, merge --reintegrate
> 13 connections total, 5 concurrent connections maximum
>
> SVN 1.8, merge
> 18 connections total, 11 concurrent connections maximum
>
> SVN 1.8, merge --reintegrate
> 5 connections total, 3 concurrent connections maximum
>
> So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
> spawns a bunch of additional connections. So, the question is - what is the maximum
> number of connections that a client can create to a server? Does it depend on the size
> of the change? Size of the svn:mergeinfo?
>
> I am not comfortable leaving the server configuration at "unlimited", seeing that
> xinetd limit is a safety net against runaway client bringing down the server.
I'm not entirely sure how to estimate the largest number
of connections made by 'svn merge'.
Note that the number of connections also depends on the amount of
svn:externals involved in checkouts and updates. One new connection
is opened for each external.
You might be interested in Ivan's RA session reuse patch:
http://svn.haxx.se/dev/archive-2013-06/0292.shtml
http://subversion.tigris.org/issues/show_bug.cgi?id=3763
This will probably be in 1.9, so it won't help you now. But I still
thought it was worth mentioning since it will address your problem
in the long term.
Re: Merge error with SVN 1.8.0
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> [copying dev@ because I found what the issue is]
>
> Hi,
>
> Did some further investigation and it turns out that SVN1.8 client creates more
> connections to the server when performing 'svn merge' - exceeding the xinetd's
> default number of connections per source (10) and indeed, closing the connection on
> an unsuspecting client. After increasing the number of connections per source to
> unlimited, the merge went through.
>
> Here are some statistics:
>
> SVN 1.7, merge --reintegrate
> 13 connections total, 5 concurrent connections maximum
>
> SVN 1.8, merge
> 18 connections total, 11 concurrent connections maximum
>
> SVN 1.8, merge --reintegrate
> 5 connections total, 3 concurrent connections maximum
>
> So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
> spawns a bunch of additional connections. So, the question is - what is the maximum
> number of connections that a client can create to a server? Does it depend on the size
> of the change? Size of the svn:mergeinfo?
>
> I am not comfortable leaving the server configuration at "unlimited", seeing that
> xinetd limit is a safety net against runaway client bringing down the server.
I'm not entirely sure how to estimate the largest number
of connections made by 'svn merge'.
Note that the number of connections also depends on the amount of
svn:externals involved in checkouts and updates. One new connection
is opened for each external.
You might be interested in Ivan's RA session reuse patch:
http://svn.haxx.se/dev/archive-2013-06/0292.shtml
http://subversion.tigris.org/issues/show_bug.cgi?id=3763
This will probably be in 1.9, so it won't help you now. But I still
thought it was worth mentioning since it will address your problem
in the long term.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
[copying dev@ because I found what the issue is]
Hi,
Did some further investigation and it turns out that SVN1.8 client creates more
connections to the server when performing 'svn merge' - exceeding the xinetd's
default number of connections per source (10) and indeed, closing the connection on
an unsuspecting client. After increasing the number of connections per source to
unlimited, the merge went through.
Here are some statistics:
SVN 1.7, merge --reintegrate
13 connections total, 5 concurrent connections maximum
SVN 1.8, merge
18 connections total, 11 concurrent connections maximum
SVN 1.8, merge --reintegrate
5 connections total, 3 concurrent connections maximum
So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
spawns a bunch of additional connections. So, the question is - what is the maximum
number of connections that a client can create to a server? Does it depend on the size
of the change? Size of the svn:mergeinfo?
I am not comfortable leaving the server configuration at "unlimited", seeing that
xinetd limit is a safety net against runaway client bringing down the server.
Regards,
Alexey.
On Sunday, June 23, 2013 12:56:27 PM Alexey Neyman wrote:
Hi,
I've tried upgrading the client to SVN 1.8, and now see some strange merge errors
while reintegrating the branch. According to
http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
the --reintegrate option is now deprecated, its use is discouraged and SVN should be
able to figure that out automatically. However, when I tried a plain "svn merge", it
gave me the following error:
[aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
svn: E210002: Network connection closed unexpectedly
Strangely, 'svn merge --reintegrate' worked fine.
We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4" version). I
installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the client.
Any clues/suggestions as to how to debug this further?
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
[copying dev@ because I found what the issue is]
Hi,
Did some further investigation and it turns out that SVN1.8 client creates more
connections to the server when performing 'svn merge' - exceeding the xinetd's
default number of connections per source (10) and indeed, closing the connection on
an unsuspecting client. After increasing the number of connections per source to
unlimited, the merge went through.
Here are some statistics:
SVN 1.7, merge --reintegrate
13 connections total, 5 concurrent connections maximum
SVN 1.8, merge
18 connections total, 11 concurrent connections maximum
SVN 1.8, merge --reintegrate
5 connections total, 3 concurrent connections maximum
So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
spawns a bunch of additional connections. So, the question is - what is the maximum
number of connections that a client can create to a server? Does it depend on the size
of the change? Size of the svn:mergeinfo?
I am not comfortable leaving the server configuration at "unlimited", seeing that
xinetd limit is a safety net against runaway client bringing down the server.
Regards,
Alexey.
On Sunday, June 23, 2013 12:56:27 PM Alexey Neyman wrote:
Hi,
I've tried upgrading the client to SVN 1.8, and now see some strange merge errors
while reintegrating the branch. According to
http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
the --reintegrate option is now deprecated, its use is discouraged and SVN should be
able to figure that out automatically. However, when I tried a plain "svn merge", it
gave me the following error:
[aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
svn: E210002: Network connection closed unexpectedly
Strangely, 'svn merge --reintegrate' worked fine.
We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4" version). I
installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the client.
Any clues/suggestions as to how to debug this further?
Regards,
Alexey.