[darcs-devel] [patch1373] refactored Darcs.Repository (and 1 more)

Guillaume Hoffmann bugs at darcs.net
Mon Oct 19 18:16:05 UTC 2015


Guillaume Hoffmann <guillaumh at gmail.com> added the comment:

I'm pasting Ganesh's comments that went on the mailing list only:

*****************

> patch 23bad6777ea545cbf8f5d2856ab3a50d190b0f8d
> Author: Ben Franksen <benjamin.franksen at helmholtz-berlin.de>
> Date:   Sun Jun 28 20:18:58 CEST 2015
>   * remove race from D.R.Packs, further simplify the code

Now I've got onto looking at this patch, I see my comments on the
previous patch may be a bit obsolete as things have moved on a bit and
now all the actions are all run to completion, now in parallel whereas
in the original code before your changes it was (I think) in serial.

One question about the followup is that now it doesn't specifically know
about the "meta-filelist-inventories" and "meta-filelist-pristine"
names. Does this matter?

I'm still rather confused by the whole module in general, I'll keep
trying to understand the intentions...

Cheers,

Ganesh

*****************

I found this specification: http://darcs.net/Internals/OptimizeHTTP

In particular the main goal of the parallel execution seems to be to
directly download files that are actually in the tarball, but in reverse
order. Even if this does lead to a wall clock speedup, I'm not sure it's
the best approach overall - it must cost bandwidth as well as adding a
lot of the complexity we see in the module.

We do need to download any patches explicitly requested that aren't in
the pack though. I'm not quite sure what the right strategy there is. If
there was a meta-filelist for the patches in the tarball we could read
that quickly (at the start of the download) and then start a parallel
thread to download patches that we know won't be in the tarball, but I
don't think there is.

I found this specification: http://darcs.net/Internals/OptimizeHTTP

In particular the main goal of the parallel execution seems to be to
directly download files that are actually in the tarball, but in reverse
order. Even if this does lead to a wall clock speedup, I'm not sure it's
the best approach overall - it must cost bandwidth as well as adding a
lot of the complexity we see in the module.

We do need to download any patches explicitly requested that aren't in
the pack though. I'm not quite sure what the right strategy there is. If
there was a meta-filelist for the patches in the tarball we could read
that quickly (at the start of the download) and then start a parallel
thread to download patches that we know won't be in the tarball, but I
don't think there is.

Ganesh

*****************

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1373>
__________________________________


More information about the darcs-devel mailing list