Re: [boost] SVN slow again?

Subject: Re: [boost] SVN slow again?
From: Joshua Juran (jjuran_at_[hidden])
Date: 2011-03-05 13:19:31

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