[pacman-dev] [PATCH] makepkg: Pass --stream to `hg clone` when creating the working copy

Eli Schwartz eschwartz at archlinux.org
Thu Sep 20 06:25:59 UTC 2018


On 9/19/18 3:15 PM, Luke Shumaker wrote:
> On Sat, 08 Sep 2018 16:31:16 -0400,
> Luke Shumaker wrote:
>> From: Luke Shumaker <lukeshu at parabola.nu>
>>
>> Without --stream, `hg clone` reencodes+recompresses the entire repository,
>> to the storage settings of the host.  But download_hg() already did that
>> on the initial network clone, and it is 100% pointless duplicated work for
>> the local clone.
>>
>> The work that this saves is CPU-bound (not disk-bound), and is restricted
>> to a single core.
> 
> After more testing, this didn't have the speed-up that I expected.
> Consider the patch withdrawn.

As a matter of curiosity, was this just "not much savings" or "not
actually saving"? What kind of practical effect does it have, ultimately?

...

I'm wondering if it's worth doing something similar elsewhere,
specifically for git clone --shared

It would save cp'ing possibly bloaty files from SRCDEST to BUILDDIR, in
the event that the two directories are on different partitions. Normally
git would optimize this away by creating hardlinks.

Downsides are:

- If SRCDEST is rm'ed then the BUILDDIR clone breaks -- but I consider
  that reasonable, plus if you re-clone to SRCDEST it magically works
  again...
- If the upstream source does a force push and SRCDEST prunes some
  commits in our ephemeral clone via git gc --auto, *and* users treat
  BUILDDIR as a place to commit changes they want to keep, they may
  get a broken repo and missing commits. Do we care about this? Worth
  noting is they will already have makepkg trying to force-reset the
  default "makepkg" branch.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20180920/d7f08af6/attachment.asc>


More information about the pacman-dev mailing list