Re: [boost] Re: Moving from CVS to Subversion? (was: Checking out latest...

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-03 00:04:50

On Wed, 02 Feb 2005 17:20:41 -0500, David Abrahams wrote

> > How come we didn't test it before changing?  Seems like we have the
> > same level of process in this new selection...
> 
> No, the process is being discussed here first in part so we can head
> off problems.

Great.  From the tone of your first response it didn't seem like it, since all
of my suggestions were simply dismissed out of hand (a bad test or FUD) -- or
at least that's how it seemed to me.  But I'm over it now...

My whole point in bringing up the mailing list move issues, was as an analogy
to the current CVS situation.  While SVN+OSL might appear to be the superior
solution at first blush, it might have significant unknown downsides and it
might not even solve the problem(s).  We should do whatever we can practically
do to figure out if there are downsides because, as we both agree, there isn't
any going back once we jump.
 
> >> > Maybe we need to have a coordinated test where we all agree to
> >> > pull down the whole repository at a certain time -- just to make
> >> > sure the machines/network/software is really up to the task?
> >> 
> >> That's a bad test IMO.  If we all hit CVS at the same time, how good
> >> do you think the response time will be?
> >
> > I don't know what the response would be with CVS and it doesn't
> > matter.  
> 
> Sure it does, if you want to prove that SVN will be worse.

I'm not trying to prove that SVN will be worse.  First of all, the proposal at
hand changes 2 variables: the hosting provider and the configuration
management system.  The stated goal is to improve the performance and
scalability of the boost repository. So SVN might be really scalable, but the
machine/network that hosts it might not be up the the task -- or vice versa. 
So my proposed test was just brainstorming -- I was trying to think of ways
that we could validate that OSL+SVN combo will be performant. 

Frankly, my guess is that SVN will be fine, but never having hosted an SVN
server I have no idea what kind of machine / network connection it takes to do
it well.  I have no idea what kind of machine OSL will host on, what sort of
network they have, and what other apps will be running on the server. We
basically don't have any idea of the current average and peak load on the
boost CVS repository.  Basically it's a shot in the dark from my view -- I
have no idea if making this move will be better or worse.  

Of course just setting up an experimental boost repository in SVN at OSL won't
put any load on the SVN server.  Since it will just be for experimentation
there won't be users doing updates, developers will just be tinkering, etc. 
It won't validate that the goal of the effort will be met -- only serve as a
way to get developers familiar with SVN.  So that's where the idea of
intentionally loading the server comes in.  It ensures that we at least give
it some sort of tryout...

> > My point was that CVS/Sourceforge has been mostly handling whatever
> > the concurrent load is today.  Yes, there's a stuck lock, slow
> > updates
> 
> and commits, and logs, ...

As I said, I see more than adequate CVS performance and a couple others also
seem reasonably satisfied as well.  I don't see constant complaints on the
list about CVS. So from my view there's no rush for this.  But I recognize
there are others interacting with CVS might have a different view.

> The slowness we're seeing in CVS would be there regardless of how 
> much server support we had.  
> ...slight rearrangement of points...
> Much of the slowness when you update occurs entirely on your local machine.

I have a smoking machine on my desk -- I assure you it is faster than the CVS
server ;-)  Seriously though, this assertion is irrelevant and unproveable. 
The performance is impacted by lots of factors: server load, network speeds, etc.

> CVS just wasn't designed to scale to projects the size of Boost.  

In terms of files, simultaneous users, what's the 'unit of size'?  If you mean
number of files, well, I'll just disagree b/c I've worked on bigger projects
effectively with CVS (closed fast LAN, dedicated fast server, fast clients). 
But probably more relevant, there are current open source projects much larger
than Boost that use CVS (try KDE for example).  Maybe they just don't care
about performance -- I don't know.  But anyway, we need to stop focusing on
what CVS is supposedly designed to do or not do and get back to why we want to
convert, what the benefits will be, and how we make sure we get the benefits
without stepping on a landmine.
 
> > If we knew what the average and peak load on the repository
> > was we could easily test that out that subversion/OSL would meet our
> > needs.  But since we don't know I was just suggesting a test that
> > would give us information.  If 10 people can't operate on the
> > respository at the same time then I'd be worried about converting.
> 
> When you say "we all agree to pull down the whole repository at a
> certain time" I didn't think you were talking about only 10 people,
> doing the typical things that they might do.

Sorry, I was a little loose with my test plan definition -- 'all' wasn't a
wise word.  As I said above, just putting the repository out there doesn't
test the performance -- so that's what I was trying to define.  A test to make
sure the new perfomance will be good.  10 users doing checkout against the
repository would probably be a good test.  100 users would be a stress test.

>...snip...
>
> > -- changing all the boost web pages that talk about CVS
> 
> Premature, IMO.

Agree.
 
> > -- telling all the users to download and learn subversion clients
> 
> Might be a good idea anyway.

Agree.

> > -- creating SSL accounts (or whatever) at OSL for all boost
> > developers
> 
> Premature, IMO.

How are we going to test the repository at OSL without this?  Won't SSL be
required for development access?  Running checkouts thru SSL is likely to be
slower and put more load on the server than without encrypting.  

> > -- setup anonymous access to the repository
> 
> Premature, IMO

Needed for performance testing.

> > -- converting the repository
> 
> Might be a good idea anyway.

A foundational test in my mind.  

> > -- getting regression testing switched over

I brought this list up to enumerate some of the costs of converting.  There is
non-trivial cost and I would hope there would be enough benefit to justify the
costs.  Personally I'm not sure I see it, but I'm willing to be pursuaded.

Jeff