I am also working on a CVS to SVN migration. I have two use cases, which are
of concern to me:
1) Initial checkout -- Standard operating procedure for my company is to:
a) create a branch for each release (once a month),
b) work on the branch,
c) merge the branch with the trunk,
d) release the new version.
I have approximately 30 developers overseas and the checkout using http and
fsfs takes about 45min locally. I have not tested it overseas yet. This
translates into ~22 hours/month, which is all billable. I have wondered if
it is possible or desirable to create a tarball of the branch an have each
developer untar on his local box then perform an update.
2) Continuous build -- The current build process performs a build each night
but I wish to move to a continuous build. The nightly build removes the
working copy then performs a checkout. One reason that has prevented
adoption of a continuous build is the time it takes to checkout the code,
perform the build and then tag the code is several hours. If I change this
so that, instead of removing the working copy, I perform a clean on each
project then follow that with an update, I should be able to get the build
time down to less that one hour. The initial setup would still be time
consuming since I have to perform the checkout of the branch, but this would
be a good time to create the tarball.
Any comments?
Faron.
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@equallogic.com]
> Sent: Thursday, October 27, 2005 12:22 PM
> To: users@subversion.tigris.org
> Subject: svn co performance
>
>
> I'm working on a changeover from CVS to SVN. One difference keeps
> causing discussion -- the fact that checkout, even with svnserve,
> takes twice as long as it does with CVS. (Never mind http, where it
> takes 3 times as long... and everything else is slower than svnserve,
> too.)
>
> I'm trying to understand if there is some fundamental reason why
> checkout has to be slow. It doesn't seem to be the 2x disk writes at
> the client side... and the network isn't working hard, either. I'm
> wondering if I should dig into this and see if it can be made better,
> but before I do that, I figure I'd better ask. If this is one of
> those "don't bother to try because it is fundamentally that way due to
> XYZ" then I can avoid bothering...
>
> paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 29 18:36:17 2005