I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts. Looking at svn.boost.org I see the server load has gone up to 23.92 which seems crazy high compared to where it was before? Any ideas? Thanks, John.
On 04/03/2011 10:37, John Maddock wrote:
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
It sounds like you're trying to make a whole new checkout every time when your checkout fails. Do you realize you can just do svn update and it will continue where it stopped?
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time :-( John.
2011/3/4 John Maddock <boost.regex@virgin.net>:
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time :-(
I experienced the same menace when I tried to checkout trunk and release branch for the first time using (checkout + update^n) end of last year. Getting a working copy took a whole day with many interruptions due to timeouts (sometimes leaving the working copy in obscure states, which made subsequent cleanup/workaround activities necessary). It was pretty awful. Now that I am working incrementally with trunk and release branch it's not pure joy but I can live with it. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Friday, March 04, 2011, John Maddock wrote:
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time
That's about where I'm at, it's almost unusable. My checkout is on an NFS mount, so that probably makes it even slower. By "timeouts", do you mean the following error? svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
On 3/4/2011 8:51 AM, Frank Mori Hess wrote:
On Friday, March 04, 2011, John Maddock wrote:
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time
That's about where I'm at, it's almost unusable. My checkout is on an NFS mount, so that probably makes it even slower. By "timeouts", do you mean the following error?
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Without looking at the logs for the particular errors... This is most likely due to the know bug in HTTPS+WebDav. It's more prevalent the busier the web server is. And since we opened the docs to the bots again, and there's now a wordpress install that's being used it's showing up more. I'm with Volodya on this.. We should try and move to using the SVN protocol directly to make things much faster for everyone. Baring that, we should move regular HTTP+WebDav ASAP. But I'll see if I can do some minor tweaks to the server to alleviate the issue. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time
That's about where I'm at, it's almost unusable. My checkout is on an NFS mount, so that probably makes it even slower. By "timeouts", do you mean the following error?
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Without looking at the logs for the particular errors... This is most likely due to the know bug in HTTPS+WebDav. It's more prevalent the busier the web server is. And since we opened the docs to the bots again, and there's now a wordpress install that's being used it's showing up more.
I'm with Volodya on this.. We should try and move to using the SVN protocol directly to make things much faster for everyone. Baring that, we should move regular HTTP+WebDav ASAP.
Can we have multiple protocols enabled in the short term? As things stand, the chances of me being able to merge anything to release, is basically zero. Sorry, John.
On 3/4/2011 10:57 AM, John Maddock wrote:
It sounds like you're trying to make a whole new checkout every time when your checkout fails.
Do you realize you can just do svn update and it will continue where it stopped?
Yes, I'm trying to do an update, I don't get more than half a lib at a time
That's about where I'm at, it's almost unusable. My checkout is on an NFS mount, so that probably makes it even slower. By "timeouts", do you mean the following error?
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Without looking at the logs for the particular errors... This is most likely due to the know bug in HTTPS+WebDav. It's more prevalent the busier the web server is. And since we opened the docs to the bots again, and there's now a wordpress install that's being used it's showing up more.
I'm with Volodya on this.. We should try and move to using the SVN protocol directly to make things much faster for everyone. Baring that, we should move regular HTTP+WebDav ASAP.
Can we have multiple protocols enabled in the short term?
I'm looking into that. Technically it's possible. But the authentication we currently use might not allow me to use it for the svnserve side.
As things stand, the chances of me being able to merge anything to release, is basically zero.
I just made one minor server change which might help. So try it now. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
As things stand, the chances of me being able to merge anything to release, is basically zero.
I just made one minor server change which might help. So try it now.
Lasted less than a minute before: svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org) Thanks for trying though! John.
On 3/4/2011 11:42 AM, John Maddock wrote:
As things stand, the chances of me being able to merge anything to release, is basically zero.
I just made one minor server change which might help. So try it now.
Lasted less than a minute before:
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Thanks for trying though! John.
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit. HTH. PS. Since the password is in the clear.. Please consider your choice of passwords carefully. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 3/4/2011 9:06 PM, Rene Rivera wrote:
On 3/4/2011 11:42 AM, John Maddock wrote:
As things stand, the chances of me being able to merge anything to release, is basically zero.
I just made one minor server change which might help. So try it now.
Lasted less than a minute before:
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Thanks for trying though! John.
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
HTH.
PS. Since the password is in the clear.. Please consider your choice of passwords carefully.
PPS. I did the above instead of svnserve because using svnserve makes for a management problem when it comes to having people provide new passwords. Any one happen to know of a web frontend for people to edit their own svnserve passwords? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
HTH.
PS. Since the password is in the clear.. Please consider your choice of passwords carefully.
Indeed, I just tried to change my password, but couldn't actually figure out how.... so I go to svn.boost.org select the "change your Subversion password" option, and that takes me to the full svnmanager page with options for everything it seems *except* resetting my password. This could just be because I have admin privileges that it's not intuitive? BTW I tried User Admin -> Edit User -> Select but that just leads to an empty page? Cheers, John.
On 3/5/2011 6:36 AM, John Maddock wrote:
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
HTH.
PS. Since the password is in the clear.. Please consider your choice of passwords carefully.
Indeed, I just tried to change my password, but couldn't actually figure out how.... so I go to svn.boost.org select the "change your Subversion password" option, and that takes me to the full svnmanager page with options for everything it seems *except* resetting my password. This could just be because I have admin privileges that it's not intuitive?
BTW I tried User Admin -> Edit User -> Select but that just leads to an empty page?
Hm, I do: 1. Login 2. User Admin 3. Edit button 4. Fill in "New password" and "Repeat new password", and old "Password". 5. Press Confirm button Perhaps you are an admin and have more options? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
BTW I tried User Admin -> Edit User -> Select but that just leads to an empty page?
Hm, I do:
1. Login 2. User Admin 3. Edit button 4. Fill in "New password" and "Repeat new password", and old "Password". 5. Press Confirm button
Perhaps you are an admin and have more options?
Yep, I don't get a change password option... John.
(This is my first post to the boost list. I've worked with Marshall Clow on Nitrogen, a C++ wrapper for Carbon.) On Mar 4, 2011, at 7:06 PM, Rene Rivera wrote:
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
Is this an appropriate time to bring up the prospect of switching to Git? Aside from the details of whether a particular secure transport layer has bugs or not, the distributed version control model allows a developer to perform integration merging locally, without requiring network access at all, much less relying on a specific server.
PS. Since the password is in the clear..
That protects any passwords you don't use. But what of the Boost SVN service itself?
... Please consider your choice of passwords carefully.
And your Internet service provider even more carefully. I'm sure everyone here understands the issues, but I'm surprised to see authentication in the clear proposed as even a temporary workaround. Is using stunnel on the server an option? Josh
On 3/5/2011 3:16 AM, Joshua Juran wrote:
(This is my first post to the boost list. I've worked with Marshall Clow on Nitrogen, a C++ wrapper for Carbon.)
On Mar 4, 2011, at 7:06 PM, Rene Rivera wrote:
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
Is this an appropriate time to bring up the prospect of switching to Git? Aside from the details of whether a particular secure transport layer has bugs or not, the distributed version control model allows a developer to perform integration merging locally, without requiring network access at all, much less relying on a specific server.
Perhaps, perhaps not.. Git might have similar problems since at some point you have to send things over the network. The problems we are having now actually don't have to do with subversion but with the choice of how we access it. Ideally we would use the svnserve protocol with SASL authentication and encryption. Or perhaps HTTP digest authentication, since we don't really need to send content encrypted only the password exchange. But any change requires that we redo all the accounts and passwords. And hence find, or write, a web utility for people to manage their password.
PS. Since the password is in the clear..
That protects any passwords you don't use. But what of the Boost SVN service itself?
... Please consider your choice of passwords carefully.
And your Internet service provider even more carefully.
I'm sure everyone here understands the issues, but I'm surprised to see authentication in the clear proposed as even a temporary workaround. Is using stunnel on the server an option?
It's only a temporary fix to get things working for people that need to commit for the 1.46.1 release. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Mar 5, 2011, at 6:15 AM, Rene Rivera wrote:
On 3/5/2011 3:16 AM, Joshua Juran wrote:
(This is my first post to the boost list. I've worked with Marshall Clow on Nitrogen, a C++ wrapper for Carbon.)
On Mar 4, 2011, at 7:06 PM, Rene Rivera wrote:
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
Is this an appropriate time to bring up the prospect of switching to Git? Aside from the details of whether a particular secure transport layer has bugs or not, the distributed version control model allows a developer to perform integration merging locally, without requiring network access at all, much less relying on a specific server.
Perhaps, perhaps not.. Git might have similar problems since at some point you have to send things over the network. The problems we are having now actually don't have to do with subversion but with the choice of how we access it.
It's true that the specific tool is not the problem. But centralized versus distributed is definitely an issue. Obviously you need to publish to a well-known location, and server availability is required for that. But the actual integration work can be performed locally. The difference is that post-merge push is a batch operation, which in the event of network issues could be left to run unattended, even automatically retrying until successful, whereas the integration process itself requires uninterrupted access to the repository. Another consideration is that SSH (commonly used for authenticated Git access) is more widely used than WebDAV, and hence less likely to exhibit serious bugs. There are alternatives (to Git over SSH) even in that case, but they tend to still require working SSH so I won't elaborate.
Ideally we would use the svnserve protocol with SASL authentication and encryption. Or perhaps HTTP digest authentication, since we don't really need to send content encrypted only the password exchange. But any change requires that we redo all the accounts and passwords. And hence find, or write, a web utility for people to manage their password.
I'm not a security expert or cryptographer by any means, but I recommend consulting one. Josh
On 3/5/2011 12:19 PM, Joshua Juran wrote:
On Mar 5, 2011, at 6:15 AM, Rene Rivera wrote:
On 3/5/2011 3:16 AM, Joshua Juran wrote:
(This is my first post to the boost list. I've worked with Marshall Clow on Nitrogen, a C++ wrapper for Carbon.)
On Mar 4, 2011, at 7:06 PM, Rene Rivera wrote:
I just turned on write-access commits from the HTTP side. So you should be able to do a checkout with authentication without HTTPS. Of course the password will be sent in the clear. The theory is that removing the HTTPS will work around the bug in HTTPS+WebDav. And of course relieve some CPU stress on the server. I was able to flawlessly do a trunk checkout, and a simple commit.
Is this an appropriate time to bring up the prospect of switching to Git? Aside from the details of whether a particular secure transport layer has bugs or not, the distributed version control model allows a developer to perform integration merging locally, without requiring network access at all, much less relying on a specific server.
Perhaps, perhaps not.. Git might have similar problems since at some point you have to send things over the network. The problems we are having now actually don't have to do with subversion but with the choice of how we access it.
It's true that the specific tool is not the problem. But centralized versus distributed is definitely an issue. Obviously you need to publish to a well-known location, and server availability is required for that. But the actual integration work can be performed locally.
It's not the integration/merge that John is having problems with.. It's just doing the checkout/get/pull. Doing the merge would work just fine since most of it doesn't involve any network traffic, and hence amounts to a small set of requests to the server (as opposed to a large response from the server).
The difference is that post-merge push is a batch operation, which in the event of network issues could be left to run unattended, even automatically retrying until successful, whereas the integration process itself requires uninterrupted access to the repository.
But that's not where we have problems. Doing the commits is usually a much smaller network exchange since you are uploading changes only to the server. And the operation is equivalent in all SCMs.
Another consideration is that SSH (commonly used for authenticated Git access) is more widely used than WebDAV, and hence less likely to exhibit serious bugs. There are alternatives (to Git over SSH) even in that case, but they tend to still require working SSH so I won't elaborate.
We wouldn't use SSH for Git. We'd more likely use HTTPS, i.e. HTTP-over-SSL. But this is all actually irrelevant.. There's a bug in how HTTPS on Apache interacts with WebDav that has never been fully fixed. And there's not much we can do about that other than not use Apache HTTPS. And the current problems with SVN are solvable. It just means actually designing the server infrastructure we use. And most of us are not expert enough, nor have the resources, to that.
Ideally we would use the svnserve protocol with SASL authentication and encryption. Or perhaps HTTP digest authentication, since we don't really need to send content encrypted only the password exchange. But any change requires that we redo all the accounts and passwords. And hence find, or write, a web utility for people to manage their password.
I'm not a security expert or cryptographer by any means, but I recommend consulting one.
I'm not an "expert".. But I'm not an "idiot" either ;-) And I have a friend and business partner who is more of an "expert" than myself in this area. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Yes, I'm trying to do an update, I don't get more than half a lib at a time
That's about where I'm at, it's almost unusable. My checkout is on an NFS mount, so that probably makes it even slower. By "timeouts", do you mean the following error?
svn: REPORT of '/svn/boost/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.boost.org)
Yep. And if we can't even check out from SVN the chances of merging a largish lib like Boost.Math from Trunk to release is basically zero: that's something that *can't* be done incrementally. In fact I'm only checking out the release branch again because a merge went bad and I had to delete libs/ and then update to get a clean copy. But I can't even do that it seems :-( John.
On 4 March 2011 09:37, John Maddock <boost.regex@virgin.net> wrote:
I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts.
Looking at svn.boost.org I see the server load has gone up to 23.92 which seems crazy high compared to where it was before? Any ideas?
Bots were unblocked for the documentation a week ago. I don't think that's the cause but I'll try claiming ownership of the site with google and decreasing the crawl rate. Daniel
participants (7)
-
Daniel James -
Frank Mori Hess -
Joachim Faulhaber -
John Maddock -
Joshua Juran -
Mathias Gaunard -
Rene Rivera