- page 1 of 379
- next ->
|bfr||Thu Jul 2 13:06:28 UTC 2015|
|ganesh||Fri Jul 3 05:39:21 UTC 2015|
|ganesh||Sun Jun 28 20:15:42 UTC 2015|
Also slightly improve the error message when invalid arguments (non-relative paths) are given for remote repos.
|bfr||Wed Jul 1 19:10:23 UTC 2015|
It turned out cancelling the other thread makes the error only less probable, I could still reproduce it. The reason is that the race is semantically incorrect: The extra patches to fetch are not a subset of the ones we get from the pack, since they may contain patches that were added after creation of the pack.
In order to further simplify the code and remove possible race conditions, the meta-filelist-xxx files are not written to disk. Instead we directly evaluate their content and pass it to fetchFilesUsingCache.
|bfr||Sun Jun 28 18:18:58 UTC 2015|
|bfr||Wed Jun 24 22:15:07 UTC 2015|
The solution is to make a case distinction between remote and local usage. If we are working in a remote location, check that file arguments are relative paths and then do the log action inside a temporary directory.
|bfr||Sun Jun 28 16:23:56 UTC 2015|
In particular, check that - no _darcs dir remains - it works if we are in a non-writeable dir - it fails if we give it an absolute filename
|bfr||Sun Jun 28 16:33:40 UTC 2015|
|bfr||Sun Jun 28 01:44:43 UTC 2015|
The module in question had a global variable implemented as an IORef which does not play well with concurrent threads. The revised implementation uses MVars and also takes care that a connection is only used by one thread at a time. This fixes severe performance problems and intermittent failures when cloning repos over ssh due to concurrent access from D.R.Packs.
Another problem was that the connections were identified by the user@host part only, but not by the directory of the repo. This causes problems when e.g. pulling from multiple ssh repos on the same user@host. We now use a (user@host, repodir) pair as the key for cached connections.
|bfr||Sun Jun 28 01:53:30 UTC 2015|
The tests sometimes fail and we do not use it in darcs (yet?).
|bfr||Mon Jun 22 07:36:28 UTC 2015|
|bfr||Mon Jun 22 07:40:03 UTC 2015|
|bfr||Sun Jun 28 13:42:25 UTC 2015|
|bfr||Sun Jun 28 18:17:21 UTC 2015|
|bfr||Sun Jun 28 12:38:52 UTC 2015|
|bfr||Sun Jun 21 22:04:21 UTC 2015|
|bfr||Sun Jun 21 22:02:39 UTC 2015|
|bfr||Sun Jun 21 11:25:30 UTC 2015|
The main difference is that we now cancel all threads when the job is done. The previous implementation left one of the threads running and I suspect (but haven't strictly verified) that this caused the error message. There is rather strong evidence though: turning on debug messages makes the problem disappear, as did turning off the concurrency (by commenting out the forkIO), both of which suggests a race condition. Then there is the fact that the clone actually succeeded despite the error message. Last not least, with this patch in effect I can no longer reproduce the problem.
|bfr||Sun Jun 21 21:54:09 UTC 2015|
|bfr||Sun Jun 14 11:22:19 UTC 2015|
This group of options is used by show files, show contents, dist, and annotate. For those commands, the intention is /not/ to select a single patch but rather all patches up to a single patch.
|bfr||Fri Jun 19 19:44:58 UTC 2015|
|bfr||Fri Jun 19 19:44:24 UTC 2015|
All the code implementing cloneRepository and createRepository moved to a separate module Darcs.Repository.Clone and only re-exported by Darcs.Repository. Only a few small functions remain in Darcs.Repository, which was certainly originally intended to be for re-exporting only.
Furthermore, moved the fetching and unpacking code used by cloneRepository and createRepository to separate module Darcs.Repository.Packs. This module now contains all the tricky concurrency code that I suspect being reponsible for causing issue2400.
This patch makes no functional changes. The only changes beside the above two large refactorings are - culling (and some sorting) of the imports - inlining of copyRepoAndGoToChosenVersion into cloneRepository - consistent use of the </> operator from System.FilePath - combine fetching and unpacking of the packs in a function
|bfr||Sun Jun 21 21:49:33 UTC 2015|
|bfr||Sat Jun 13 21:30:53 UTC 2015|
|bfr||Sun Jun 21 20:52:21 UTC 2015|
|bfr||Fri Jun 19 22:27:23 UTC 2015|
This patch is supposed to be semantically transparent. It mainly consists of reducing the number of times the flag list is parsed to extract the matchFlags from three to one.
|bfr||Fri Jun 19 21:53:20 UTC 2015|
The dist command accepts only non-range matching options, so this extra case distinction is just dead code.
|bfr||Fri Jun 19 21:45:17 UTC 2015|
The crucial change here is that we don't use readRecorded if called with a match option. Instead we call getNonrangeMatch in an empty (temporary) tree, quite similar to how this is done in D.UI.Command.ShowFiles.
This patch also refactors the code quite a bit and adds some comments to explain the tricky bits.
|bfr||Fri Jun 19 21:34:11 UTC 2015|
This is a necessary (but not yet sufficient) part of resolving issue2447. The problem here is that H.S.M.fileExists returned False when the tree was not expanded, even if the expanded tree does contain the file. This caused 'darcs show contents' to erroneously ignore the file.
What remains for issue2447 to be resolved is to make 'darcs show contents' use the virtualTreeIO in all cases.
|bfr||Fri Jun 19 20:58:40 UTC 2015|
- page 1 of 379
- next ->