5 patches for repository http://darcs.net/screened:
patch 98f5af0b26825b607402ce2f4ad280504b604059
Author: Ben Franksen <ben.franksen@online.de>
Date: Sat Dec 26 19:47:09 CET 2020
* remove a redundant call to nub
patch f23b9cf168fc84cc4b9d8b81493f76ee377cb7da
Author: Ben Franksen <ben.franksen@online.de>
Date: Tue Dec 22 15:02:36 CET 2020
* make sure repoLocation is an absolute or remote path
The mkRepo constructor now takes an AbsoluteOrRemotePath instead of a
String.
patch 85eb660cd2b5ea3666e0cadc41fdb067ceb14a69
Author: Ben Franksen <ben.franksen@online.de>
Date: Tue Jan 5 12:06:58 CET 2021
* remove redundant readProblem check in cloneRepository
We have just called identifyRepositoryFor which check for transferProblem
which in turn includes the readProblem check.
patch 7940ff17b2214fa9fc0828ae049e1bb070acaeb1
Author: Ben Franksen <ben.franksen@online.de>
Date: Sun Dec 27 21:27:11 CET 2020
* resolve issue2672: extraneous "repo:." entries in _darcs/prefs/sources
The fix changes the second argument of getCaches from String to Maybe
AbsoluteOrRemotePath. The implementation of getCaches makes it pretty clear
that its second parameter is supposed to be the location of a "remote" repo
(something different from "."). Indeed, getCaches /always/ evaluates the
local sources file under ".", in addition to the one under the url we pass
it. Passing "." as the second parameter is responsible for creating the
unwanted extraneous cache entries. This explains the Maybe. Using
AbsoluteOrRemotePath instead of String serves to ensure that cache entries
cannot be relative paths.
This change makes the network/lazy-clone test fail. This is not a bug but an
overspecification in the test. This is fixed in another patch together with
an explanation of why exactly the test fails.
patch 29a64db7f50f073a7fdd2fcedafb614c515b5756
Author: Ben Franksen <ben.franksen@online.de>
Date: Sun Jan 10 11:18:31 CET 2021
* fix overspecification in network/lazy-clone
This test succeeded only because of issue2672. Indeed, the presence of the
bogus (Cache Repo NotWritable ".") entry means that this source will be used
when we speculate on patches (instead of the actual remote repo), which
effectively disables speculating. With issue2672 fixed, speculating on patch
files now works, however it seems that we speculate on too many patches (on
my computer /all/ patches are now downloaded). The reason for this
unexpected behavior is that the tag in question is not clean in the source
repo (unpacked from tests/data/tabular.tgz), which means we speculate on
patches that we don't actually need. To get more predictable results here, I
made all tags clean (so each tag gets its own inventory). This now results
in downloading exactly the number of patches after the tag (42, as many as
we have to unapply), so the number of "unavailable" patches is now 33=75-42
as expected (75 being the total number of patches).
Attachments
|
