Re: [boost] SVN slow again?

Subject: Re: [boost] SVN slow again?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-03-05 09:15:58

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