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

[Adolfo Builes]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100626/9ab98ee1/attachment.html>