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

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-03 23:25:24

On Thu, 03 Feb 2005 10:13:20 -0500, David Abrahams wrote
> "Jeff Garland" <jeff_at_[hidden]> writes:
>
> > Great.  From the tone of your first response it didn't seem like it,
> 
> Check the subject line.  The question mark there was intentional.

That was subtle, didn't enter into my thinking later...

> > 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.
> 
> IIRC you made only one suggestion, which after some consideration I
> thought was not a good test. 

I think the problem was you didn't say why -- we've clarified that since...

> The rest were just fears with no proposal for action, again IIRC.

Well, my sentence had a question mark too -- I was basically asking if others
had good ideas for tests.  I'd say some have since emerged...
 
> Well, we can certainly do some serious testing without jumping.  And,
> in fact, there is going back.  It would be very painful, but we could
> generate a script from the SVN repository and ask the SF guys to run
> it.  But I'd rather avoid that.

The pain of going back would be pretty difficult to imagine...
 
> >From what I've been told, OSL has a fast connection, and loads of money
                                                             ^^^^^^^^^^^^
That's suprising, but if it's true, that's great.

> >  -- or vice versa.  
> 
> ?? The task might not be up to the machine/network?

I'll try again.  Since we are changing 2 variables: SVN and the hosting, one
or the other might not be up to the challenge.
 
> I think deductive reasoning is probably the best approach on this 
> one, because I don't think we're going to be able to create a sufficiently
> wide range of realistic usage patterns.  Not least because we don't
> know how many people are using the CVS, and how.
>
> > 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.  
> 
> Again, deductive reasoning is probably a good tool here: find out 
> what gets sent across the network; do some research into the 
> relative demands of CVS and SVN on resources.

I don't really want to argue this any more.  Let's just agree to disagree.  I
don't believe logic will work with all the unknown variables.  I think some
sort set of tests are required to validate that the new environment won't just
fall flat on it's face.

> > Of course just setting up an experimental boost repository in SVN at
> > OSL won't put any load on the SVN server. 
> > ...
> 
> I like it in principle, but without the information you mentioned
> earlier about the CVS repository loads, how will we draw any
> conclusions from the results?

The only conclusion we can draw is that whatever test we do didn't break
things.  It's far from perfect, but I still prefer this to reading about what
the software supposedly does and doesn't do and guessing at whether it will
work.  

> >  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.
> 
> Okay, that sounds reasonable.  Although I doubt cvs checkout is ever
> done by more than a few people at once.  More likely update.

Sure update is fine.  However, since SVN wants atomic repository commits maybe
we should have someone do a big checkin while others are updating.
 
> >> > -- 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?  
> 
> Probably.  But we don't need access for "all" boost developers,
>  unless by "all" you mean ten of us again.

Well we can start with some subset, but all (this is really all ;-) of us will
need to get used to the new environment over some period of time.  Even if
there is some other place to do that, I'd prefer to use something as close as
possible to the final environment -- hate to learn details that don't turn out
to be relevant to the final solution.  
 
> > Running checkouts thru SSL is likely to be slower and put more load
> > on the server than without encrypting.
> 
> I'm not sure whether encryption is actually used for anything other
> than authentication, but your point is taken nonetheless.

Should probably only be required for autentication to allow write access since
we don't have any info we are trying to keep hidden.  But someone will have to
work out the details of the security model.

> >> > -- setup anonymous access to the repository
> >> 
> >> Premature, IMO
> >
> > Needed for performance testing.
> 
> You don't think we can do the tests with 10 developers' https://
> access?  Not that I object to setting up anonymous access, or
> anything.

It might be enough to do 10, but do you think that's representative of the
peak load on the repository?   Anyway, whomever designs the security model
will have to figure this out and set it up anyway.

> I don't have much to say other than to say that some of us spend a 
                                                  ^^^^^^^^^^
Haven't heard from too many others yet in this thread...speak up folks, this
isn't the Dave and Jeff show...

> lot of time waiting for CVS, there are constant stale locks, our 

Constant being once a day, week, month?  Of course, it takes a long time to
get SF folks to fix this so it's a big pain when it happens...

> occasional file moves are painful, 

No doubt SVN would be better at this.  Directory versioning would be very
nifty to have as well.

> and the anonymous pserver image lags the real one by an hour or 
> more.  

Agree, that's a pain for me too.  

> Oh, and SF's connection for getting the CVS tarball keeps 
> dropping, so it's hard for anyone to do automated backups.

Ok, since I don't pull those I wouldn't see that.  Of course this is really a
SF problem not a CVS problem.  But obviously this could be improved by moving
to OSL.

> But if you aren't having any trouble, there may not be much anyone 
> can do to persuade.

Well, I'm persuaded we should continue investigating the option if we have
volunteers willing to put in time -- which it sounds like we do.  But I think
the process will take months. We will need to have a someone at OSL to work
all the setup details (passwords, berkley db or fsfs, anonymous access, CVS
conversion, etc, etc).  It's going to be alot of work....

The only other nagging thing for me is while we spend our energy going down
this path, the review queue is stuck b/c we haven't found a review manager to
run the Wave review (I think I saw 2 posts from Tom with no answer).  So we
need others to step forward so we don't lose our momentum on library building
front...

Jeff