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

[OT] commit methodology (was: Re: CVS update: ...)

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-03-29 10:25:07 CEST

On Thu, Mar 29, 2001 at 09:42:05AM +0200, Joost Baaij wrote:
> Let me introduce myself ..

Welcome!

> I currently work as manager Q&A. My job is to review documents and code,
> produce documentation, and make sure everyone's talking to everyone and using
> the right tools (such as CVS).
>
> I've joined subversion-dev because I'm not happy with CVS and I believe this
> could replace it. I can probably help you guys with the documentation.

Great!

> Karl Fogel wrote:
> > It's important that the build and test suite be in a happy state in
> > the repository most of the time, to facilitate parallel development.
> > If I've checked in code that breaks "make check", then it's going to
> > be harder for others to test their own changes, even though their own
> > changes might not be related to what I'm doing.
>
> Should anyone be allowed to check in code that breaks any tests? Personally I
> think someone should only commit code when all the tests pass on his/her local
> machine.

This is a bit off-topic for this list, but what the heck. IMO, yes, people
can/should be able to check in stuff according to whatever guidelines they
care to impose upon themselves.

For example, I make changes all the time and never run the test suite. In
some cases, it is simply to fix a compilation issue caused by an API change
elsewhere. I know that isn't going to affect the test suite. In other cases,
the code that I'm working on is not covered by the test suite, so there
isn't a need to run it.

And your next words will be, "but that code should have a test suite, then!"
Well, there is a large gap between "should" and "does" :-) When somebody
wants to build a test suite that can adequately test mod_dav_svn and
libsvn_ra_dav, then I'd be happy to use it. Until then, they remain well out
of the reach of automated testing.

[ some of the new cmdline testing stuff should help, but it is still awfully
  difficult because of the number of pieces that need to be set up,
  configured, and run; then there is the test configuration to map to that
  setup; then the number of external dependencies that can impact it; etc.
  Library testing is cake compared to testing client/server pieces. ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:26 2006

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.