On Oct 29, 2005, at 18:32, Faron Dutton wrote:
> 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.
> 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.
Why are you checking out often? Check out the branch once. Work. When
done with the branch, when it has been merged and there's a new
branch you need to work on, "svn switch" the working copy you have to
the new branch. It will be quick, because the server will only have
to send you the difference between what you had and what you want.
> 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
> working copy then performs a checkout. One reason that has prevented
> adoption of a continuous build is the time it takes to checkout the
> 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
> 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.
By all means, keep the working copy and update it. Optionally, in
case you can't trust your "clean" script to clean up entirely (I
understand this happens often), write a script that runs "svn revert -
R /path/to/wc" to first discard any changes that may have been made,
then run "svn status" and parse the output and manually remove any
unversioned files that may have been left over. Then you can "svn
update" and then build again.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 29 20:13:00 2005