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

Re: [PATCH]remove adm_access in svn_wc_translated_file3

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Fri, 7 Aug 2009 06:46:18 -0500

On Aug 7, 2009, at 5:21 AM, Stefan Sperling wrote:

> On Fri, Aug 07, 2009 at 09:55:36AM +0800, HuiHuang wrote:
>>> Did you run the regression tests on this patch? I get the following
>>> errors:
>>> At least one test FAILED, checking /Users/Hyrum/dev/svn-trunk2/
>>> tests.log
>>> FAIL: merge_tests.py 40: conflict markers should match the file's
>>> eol
>>> style
>>> FAIL: special_tests.py 8: merge file into symlink
>>> FAIL: trans_tests.py 2: update modified file with eol-style
>>> 'native'
>>> FAIL: update_tests.py 27: conflict markers should match the file's
>>> eol style
>>> FAIL: update_tests.py 28: handle eol-style propchange during update
>> Sorry for the failures.
>> hmm...I want to know how do you run the tests?
> On Linux, you can run 'make check'.
> On windows, there is a script called win-tests.py. Run that script
> to run all tests.
>> Should I run the entire test everytime I make a new patch?
> Yes! Please run *all* tests before submitting a patch.
>> There are more than 70 tests and it would take a lot of time to
>> run all tests.
> Test failures often pop up in unexpected places. For example,
> your last patch broke copy test 66 and because none of us tested
> the copy tests before commit (I just ran the commit tests) this
> wasn't noticed at first. So I, too, should have run the entire
> test suite...

Let me just second this, especially when working with wc-ng. Almost
every test hits the working copy, and most exercise it in different
ways. We currently have 1145 tests that expected to pass, and some of
my initial patches only fail on one or two of them. Running the
entire test suite means I get lots of testing on my patch, and I don't
have to guess where the 0.2% of tests that fail might be.

> We are trying to keep the entire test suite running for everyone,
> all the time. Because when you make a change and you see a test
> failure, you have to go and figure out if your own change broke
> the test of if some other change broke it. When too many tests keep
> failing, it is very hard and time-consuming to verify your own changes
> and the test suite becomes useless. We were in such a situation
> sometimes and it really, really sucked.
> The test suite also takes about an hour to run for me. But as long as
> it is just my computer spending the time and not myself, I don't
> really
> care. I can do something else while the tests are running, e.g. read
> mail or put up the laundry or something.

I can usually run the entire test suite in about 35 minutes, but I've
got multiple working copies, so that while one is running tests, I can
be hacking something (usually unrelated) else in the other.


Received on 2009-08-07 13:46:37 CEST

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.