darcs

Patch 1888 remove no-packs option

Title remove no-packs option
Superseder Nosy List bf
Related Issues
Status in-discussion Assigned To
Milestone

Created on 2019-08-21.07:30:06 by bf, last changed 2019-08-22.08:06:15 by bf.

Files
File name Status Uploaded Type Edit Remove
patch-preview.txt bf, 2019-08-21.07:30:06 text/x-darcs-patch
remove-___no__packs-option.dpatch bf, 2019-08-21.07:30:06 application/x-darcs-patch
unnamed bf, 2019-08-21.07:30:06 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg21159 (view) Author: bf Date: 2019-08-21.07:30:06
1 patch for repository http://darcs.net/screened:

patch bcd2ce3941899da6747cabcb0eb5f96af502dabc
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Nov 13 17:52:24 CET 2018
  * remove --[no-]packs option
  
  I can't see any reason not to use packs if available in the remote repo.
Attachments
msg21163 (view) Author: ganesh Date: 2019-08-21.17:31:18
Might it be useful if debugging a problem with cloning (either
as a user or a developer)? e.g. if there's some problem with the
remote packs.
msg21164 (view) Author: bf Date: 2019-08-21.21:17:23
> Might it be useful if debugging a problem with cloning (either
> as a user or a developer)? e.g. if there's some problem with the
> remote packs.

I guess that was the idea. But we fall back to getting patches normally
anyway if anything fails with the packs:

copyCompleteRepoPacked from to verb cloneKind =
    copyCompleteRepoPacked2 from to verb cloneKind
  `catch`
    \(e :: SomeException) -> do
      putStrLn ("Exception while getting patches pack:\n" ++ show e)
      putVerbose verb $ text "Problem while copying patches pack,
copying normally."
      copyCompleteRepoNotPacked from to verb cloneKind

Cheers
Ben
msg21166 (view) Author: ganesh Date: 2019-08-21.22:18:57
Presumably not all problems would be detected, e.g. if the packs
appeared correct but contained wrong data.

Anyway, I don't mind if it helps clean something up.
msg21167 (view) Author: bf Date: 2019-08-22.08:05:47
> Presumably not all problems would be detected, e.g. if the packs
> appeared correct but contained wrong data.

Hm, yes, that's right.

> Anyway, I don't mind if it helps clean something up.

Not really. I just stumbled over this option and thought: would I ever
want to use --no-packs? You gave a good answer to that, so let's keep it
for now; I'll mark the patch as in-discussion, perhaps I'll come back to it.
History
Date User Action Args
2019-08-21 07:30:06bfcreate
2019-08-21 07:58:44bfsettitle: remove -- -> remove no-packs option
2019-08-21 17:31:18ganeshsetmessages: + msg21163
2019-08-21 21:17:24bfsetmessages: + msg21164
2019-08-21 22:18:57ganeshsetmessages: + msg21166
2019-08-22 08:05:47bfsetmessages: + msg21167
2019-08-22 08:06:15bfsetstatus: needs-screening -> in-discussion