Re: [boost] SVN slow again?

Subject: Re: [boost] SVN slow again?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-03-05 14:52:26

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