Hi Eric<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
> +rm -rf S sources<br>
> +darcs get <a href="http://darcs.net/testing/repo1" target="_blank">http://darcs.net/testing/repo1</a> S --no-cache<br>
> +darcs unrecord -a --repo S<br>
> +rm S/_darcs/patches/*<br>
<br>
> +echo "repo:<a href="http://10.1.2.3" target="_blank">http://10.1.2.3</a>" >> S/_darcs/prefs/sources<br>
<br>
Is this just supposed to stand in for some sort of unreachable address?<br>
What if the user happens to have a Darcs repository served up from that<br>
address on their private network? (A valid answer is "we don't care; it's<br>
just such a specific case that it won't really matter in practice").<br>
<br></blockquote><div>Exactly, we don't really care about it, is a very specific case.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Why do we think that we'll never try to connect to 10.1.2.3? Is it<br>
because of the order of the sources list?<br>
<br>
> +tac S/_darcs/prefs/sources >> sources<br>
> +mv sources S/_darcs/prefs/sources<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On IRC, we found that tac is not available by default on MSYS, so we'll have to<br>
find another way get the desired result. Do you just want to prepend the bad<br>
entry to the sources?<br>
<br></blockquote><div><br>Yes, I want to prepend.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
OK, this is expecting a "Couldn't connect" message which you plan to implement.<br>
Is it useful to output timings in this test?<br>
<br></blockquote><div>At the moment I don't see if the time would be useful or not. <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Your test seems to be checking if one source is preferred over another by<br>
testing that it never complains about not being able to connect to the<br>
less-preferred source. Is that correct or have I completely missed something<br>
here? How do you ensure that the preference is not accidental (that the test<br>
isn't just passing for the wrong reason?)
</blockquote><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Also, doesn't Darcs have to try and connect to the source to know if it's<br>
reachable or not?<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Does your test rely on some sort of timing out? That could make the network<br>
tests a bit annoying to run (especially if you want to do a lot of testing<br>
while debugging). Is there any reasonable way to test failure without<br>
requiring some sort of timeout? Is there a simple way to set things up to fail<br>
instantly?<br></blockquote><div><br>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. <br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
For the case of reachable server but non-existent repo, I suppose you could<br>
throw together (or expect) some really stupid HTTP server that just<br>
systematically 404s and then connect to localhost:some-port. But this<br>
does not give us a way to deal with unreachable addresses. I wonder if<br>
there's a nice way to do this, perhaps with the cooperation of the<br>
testing environment (for example, users have to fiddle with their config<br>
so that trying to connect to a particular IP name or domain name<br>
instantly fails without a timeout). I am way out of my element here, so<br>
don't look at me for any hints!<br>
<br></blockquote><div><br><br>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.<br>
<br>Also for the case of reachable server but non-existent repo I would think is okay to delete that entry.<br><br>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.<br>
<br><br>Cheers,<br><br>Adolfo.</div><div> </div></div>