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

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

From: Karl Fogel <kfogel_at_collab.net>
Date: 2001-03-30 01:23:37 CEST

+1

(When I said "please don't break 'make check'" in my previous mail, I
meant that how you do that is up to you. Whether you run the test
suite before every commit is your business -- a matter of personal
policy. Only when the rest of us start being affected do we get the
right to nose in. :-) )

-K

Greg Stein <gstein@lyra.org> writes:
> 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.