[darcs-users] [patch288] Failing test for issue1599: expire unused caches

Eric Kow kowey at darcs.net
Fri Jun 25 15:12:34 UTC 2010


> hunk ./tests/network/failing-issue1599-automatically-expire-unused-caches.sh 26

As you pointed out in issue1874, this may require updating our cabal test
hooks to support failing network tests in some capacity.  I've made a note
to work on this.  In the meantime, you can work on a non-failing test locally

> +rm -rf S sources
> +darcs get http://darcs.net/testing/repo1 S --no-cache
> +darcs unrecord -a --repo S
> +rm S/_darcs/patches/*

> +echo "repo:http://10.1.2.3" >> S/_darcs/prefs/sources

Is this just supposed to stand in for some sort of unreachable address?
What if the user happens to have a Darcs repository served up from that
address on their private network?  (A valid answer is "we don't care; it's
just such a specific case that it won't really matter in practice").

Why do we think that we'll never try to connect to 10.1.2.3?  Is it
because of the order of the sources list?

> +tac S/_darcs/prefs/sources >> sources
> +mv sources S/_darcs/prefs/sources

On IRC, we found that tac is not available by default on MSYS, so we'll have to
find another way get the desired result.  Do you just want to prepend the bad
entry to the sources?
 
> +darcs pull -a --verbose --debug --timing --repo S 2> log
> +not grep "Couldn't connect" log

OK, this is expecting a "Couldn't connect" message which you plan to implement.
Is it useful to output timings in this test?

Your test seems to be checking if one source is preferred over another by
testing that it never complains about not being able to connect to the
less-preferred source.  Is that correct or have I completely missed something
here?  How do you ensure that the preference is not accidental (that the test
isn't just passing for the wrong reason?)

Also, doesn't Darcs have to try and connect to the source to know if it's
reachable or not?

Does your test rely on some sort of timing out?  That could make the network
tests a bit annoying to run (especially if you want to do a lot of testing
while debugging).  Is there any reasonable way to test failure without
requiring some sort of timeout?  Is there a simple way to set things up to fail
instantly?

For the case of reachable server but non-existent repo, I suppose you could
throw together (or expect) some really stupid HTTP server that just
systematically 404s and then connect to localhost:some-port.  But this
does not give us a way to deal with unreachable addresses.  I wonder if
there's a nice way to do this, perhaps with the cooperation of the
testing environment (for example, users have to fiddle with their config
so that trying to connect to a particular IP name or domain name
instantly fails without a timeout).  I am way out of my element here, so
don't look at me for any hints!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100625/ad571048/attachment.pgp>


More information about the darcs-users mailing list