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