[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Performance Question

From: Sean Laurent <sean_at_neuronfarm.com>
Date: 2005-01-11 18:36:45 CET

On Tuesday 11 January 2005 11:19 am, Brass Tilde wrote:
> > > If you're talking about files that are the result of the build, then
> > > the build process should take care of cleaning those up.
> >
> > "Should" - yes. Purely hypothetically, there could be bugs in code. Also
> > in Makefiles... ;-D
> That sounds an awful lot like you think svn should account for possible
> deficiencies in the build system. Is that what you intended?

This is definitely something I encountered when working for a larger company
developing retail, shrink-wrap software. We used Perforce and developers
generally checked out working copies and used them for long periods of time.
However, we setup our automated build system, which ran nightly, to always
use a brand spanking new checkout every time.


For precisely the reason mentioned above. Although all of the members of our
development team were topnotch engineers, sometimes we made mistakes.
Sometimes the build process did _not_ cleanup properly. To improve quality
assurance and reduce the possibility of stray bugs getting introduced, we
wanted daily builds to reflect the codebase exactly.

While it took 30 minutes to pull down the codebase over the LAN, we observed
that doing a full checkout for every 'official' build of the software
definitely decreased inconsistencies between builds. Over the long term,
this process also reduced the occurence of the dreaded "unable to repro"

Were we using the SCM software to "account for possible deficiencies in the
build system"? Yup. Was this a "bad thing"? Nope.


Whenever I feel blue, I start breathing again.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 11 18:38:58 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.