Skip to content
Snippets Groups Projects
  1. Oct 17, 2017
    • Joey Hess's avatar
      Improve behavior when -J transfers multiple files that point to the same key · 68a49adc
      Joey Hess authored
      After a false start, I found a fairly non-intrusive way to deal with it.
      Although it only handles transfers -- there may be issues with eg
      concurrent dropping of the same key, or other operations.
      
      There is no added overhead when -J is not used, other than an added
      inAnnex check. When -J is used, it has to maintain and check a small
      Set, which should be negligible overhead.
      
      It could output some message saying that the transfer is being done by
      another thread. Or it could even display the same progress info for both
      files that are being downloaded since they have the same content. But I
      opted to keep it simple, since this is rather an edge case, so it just
      doesn't say anything about the transfer of the file until the other
      thread finishes.
      
      Since the deferred transfer action still runs, actions that do more than
      transfer content will still get a chance to do their other work. (An
      example of something that needs to do such other work is P2P.Annex,
      where the download always needs to receive the content from the peer.)
      And, if the first thread fails to complete a transfer, the second thread
      can resume it.
      
      But, this unfortunately means that there's a risk of redundant work
      being done to transfer a key that just got transferred.
      That's not ideal, but should never cause breakage; the same
      thing can occur when running two separate git-annex processes.
      
      The get/move/copy/mirror --from commands had extra inAnnex checks added,
      inside the download actions. Without those checks, the first thread
      downloaded the content, and then the second thread woke up and
      downloaded the same content redundantly.
      
      move/copy/mirror --to is left doing redundant uploads for now. It
      would need a second checkPresent of the remote inside the upload
      to avoid them, which would be expensive. A better way to avoid
      redundant work needs to be found..
      
      This commit was supported by the NSF-funded DataLad project.
      68a49adc
    • Joey Hess's avatar
      59435935
    • Joey Hess's avatar
      idea · 9606f6e8
      Joey Hess authored
      9606f6e8
    • Joey Hess's avatar
      update windows build scripts to use stack · 59a0308f
      Joey Hess authored
      Not tested yet.
      
      The EvilLinker workaround is removed. That got fixed in ghc 8.0.1,
      (per https://ghc.haskell.org/trac/ghc/ticket/8596)
      which will finally be used by the windows autobuilder now.
      
      I have not deleted the EvilLinker yet (or closed its bugs).
      
      This commit was sponsored by John Peloquin on Patreon.
      59a0308f
    • Joey Hess's avatar
      new lts · 193b5f4c
      Joey Hess authored
      193b5f4c
    • https://launchpad.net/~barthelemy's avatar
      No commit message · 65847905
      https://launchpad.net/~barthelemy authored
      No commit message
      65847905
  2. Oct 16, 2017
  3. Oct 15, 2017
  4. Oct 12, 2017
  5. Oct 11, 2017
  6. Oct 10, 2017