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

Re: SVNSERVE Tests Failing

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2003-02-01 17:11:14 CET

On Sat, Feb 01, 2003 at 04:35:56PM -0600, Karl Fogel wrote:
> The more general issue is harder to solve. Our test suite takes (on
> my development box) about a half-hour to run over any given RA layer.
> That means that each RA layer we add adds a half-hour of testing time.
> I can run the tests over ra_svn more often, but that will mean
> sometimes *not* running them over dav, or local. More likely, I'll
> run some subset of the tests over each of the ra layers, as a sanity
> check (I should really have started doing that earlier). It's not
> ideal, but an 1.5 hour test run for every change is not sustainable.
> Development would slow down too much.

Can I take this opportunity to promote something that I have recently started
doing at work?

On my team at work, each developer has a private branch of the code we work
on. We're free to do whatever we want on that branch, and use it to
checkpoint however we choose.

However, in order to merge our changes into the main development branch (which
we do about once per week), we have to make sure that we can build both debug
and release versions (not really applicable here), and pass a large suite of
tests on both debug and release builds. Of course we also have an automated
system that we submit patches to, and it performs all these checks for us,
then checks in the change if they all pass.

This allows us to check in small changes, yet maintain quality on the main

Maybe svn should try something similar.

Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall

  • application/pgp-signature attachment: stored
Received on Sun Feb 2 00:14:28 2003

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

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