darcs

Patch 288 Failing test for issue1599: expire unused caches

Title Failing test for issue1599: expire unused caches
Superseder Nosy List abuiles, kowey
Related Issues
Status obsoleted Assigned To abuiles
Milestone

Created on 2010-06-25.14:29:31 by abuiles, last changed 2013-02-18.09:53:59 by gh. Tracked on DarcsWatch.

Files
File name Status Uploaded Type Edit Remove
failing-test-for-issue1599_-expire-unused-caches.dpatch abuiles, 2010-06-25.14:29:31 text/x-darcs-patch
unnamed abuiles, 2010-06-25.14:29:31
unnamed abuiles, 2010-06-25.14:31:25 text/html
unnamed abuiles, 2010-06-27.00:59:38 text/html
See mailing list archives for discussion on individual patches.
Messages
msg11591 (view) Author: abuiles Date: 2010-06-25.14:29:31
1 patch for repository http://darcs.net:

Thu Jun 24 18:09:04 COT 2010  builes.adolfo@googlemail.com
  * Failing test for issue1599: expire unused caches
Attachments
msg11592 (view) Author: abuiles Date: 2010-06-25.14:31:25
That's a first sketch of the failing test for issue1599 but I have to
complete it.

For this test I'm assuming that when the patch is done, it shouldn't try to
connect to a bad repo, so for example the message  "Couldn't connect"
shouldn't appear, that's why I use it to make the test fail.
What I imagine is that it should know before trying to get it, if it is
available or not, so it can skip it.

There is something I'm missing here, an is that the test at the moment just
works for unreachable http, but I still need to add ssh and local,  should I
include the other two test in the same file or as separated ?.
Something like a test inside the test for locals, ssh and http ( the order
doesn't matter ).

--
Adolfo


On Fri, Jun 25, 2010 at 9:29 AM, Adolfo Builes <bugs@darcs.net> wrote:

>
> New submission from Adolfo Builes <builes.adolfo@googlemail.com>:
>
> 1 patch for repository http://darcs.net:
>
> Thu Jun 24 18:09:04 COT 2010  builes.adolfo@googlemail.com
>  * Failing test for issue1599: expire unused caches
>
> ----------
> files: failing-test-for-issue1599_-expire-unused-caches.dpatch, unnamed
> messages: 11591
> nosy: abuiles
> status: needs-review
> title: Failing test for issue1599: expire unused caches
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/patch288>
> __________________________________
Attachments
msg11594 (view) Author: kowey Date: 2010-06-25.15:09:32
> 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
msg11598 (view) Author: abuiles Date: 2010-06-27.00:59:38
Hi Eric

> +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").
>
> Exactly, we don't really care about it, is a very specific case.



> 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
>

Yes, although we do a sorting we don't have control over how the http or ssh
or locals get sorted, with that I mean, between two http it doesn't know
which one should come first.


> 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?
>
>
Yes, I want to prepend.


> OK, this is expecting a "Couldn't connect" message which you plan to
> implement.
> Is it useful to output timings in this test?
>
> At the moment I don't see if the time would be useful or not.


> 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?
>

You are right, actually I'm wrong here, my question in the test is
wrong,when the patch for this is done I imagine it shouldn't fail when
trying to fetch a file, it just will try for sources which are reachable,
before that It will have to check somehow that the specific source is
available/reachable.


> 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?
>

Well in this case timing out is not really that import, I'm just generating
an error when trying to fetch for an external source, we could also use just
an invalid address.

 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!
>
>

For the time-out, I have thought about the possibility of including a
default waiting time, something like 15 seconds and bring the possibility to
the user to change it, so if for example if we get 15 seconds waiting for a
server to answer back we can just skip it and try the next one.

Also for the case of reachable server but non-existent repo I would think is
okay to delete that entry.

I have had some thoughts about what is saved in the sources file, we agree
that we need to keep the repos when they are lazy, but for example if a get
a repo non-lazily, do we really need to put that in sources ? We already
have it in default repo, also I have been thinking whether do we really need
to put in sources all the repos from which we pull from.


Cheers,

Adolfo.
Attachments
msg16694 (view) Author: gh Date: 2013-02-18.09:53:59
Marking as obsoleted since the following version of this bundle is 
present in the repo:

1: Sat Aug  7 23:11:43 CEST 2010  builes.adolfo@googlemail.com
  * Test for issue1599: expire unused caches
History
Date User Action Args
2010-06-25 14:29:31abuilescreate
2010-06-25 14:31:17darcswatchsetdarcswatchurl: http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-674e1ef875717d6e43f224a9689cf5f212a9dc2d
2010-06-25 14:31:26abuilessetfiles: + unnamed
messages: + msg11592
2010-06-25 15:09:32koweysetnosy: + kowey
messages: + msg11594
2010-06-25 15:42:13koweysetstatus: needs-review -> in-discussion
2010-06-27 00:59:39abuilessetfiles: + unnamed
messages: + msg11598
2010-07-01 10:10:14koweysetstatus: in-discussion -> followup-in-progress
assignedto: abuiles
2011-05-10 18:06:44darcswatchsetdarcswatchurl: http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-674e1ef875717d6e43f224a9689cf5f212a9dc2d -> http://darcswatch.nomeata.de/repo_http:__darcs.net_reviewed.html#bundle-674e1ef875717d6e43f224a9689cf5f212a9dc2d
2013-02-18 09:53:59ghsetstatus: followup-in-progress -> obsoleted
messages: + msg16694