On 2018-11-09 16:05:06, Antoine Beaupré wrote:
> 2. do a crazy filter-branch to send commits to the right
> files. considering how long an initial clone takes, i can't even
> begin to imagine how long *that* would take. but it would be the
> most accurate simulation.
>
> Short of
On 2018-09-26 14:56:16, Daniel Lange wrote:
[...]
> In any case, a repo with just the split files but no maintained history clones
> in ~12s in the above test setup. It also brings the (bare) repo down from
> 3,3GB
> to 189MB. So the issue is really the data/CVE/list file.
So I've looked in
Hi,
[not contributing right now with ideas, just giving one important
datapoint to me to the discussion]
On Wed, Sep 26, 2018 at 03:15:14PM +0200, Guido Günther wrote:
> Not necessarily. Maybe a graft would do:
>
>
>
Hi,
On Wed, Sep 26, 2018 at 01:56:16PM +0200, Daniel Lange wrote:
> The main issue is that we need to get clone and diff+render operations
> back into normal time frames. The salsa workers (e.g. to render a
> diff) time out after 60s. Similar time constraints are put onto other
I wonder why that
The main issue is that we need to get clone and diff+render operations
back into normal time frames. The salsa workers (e.g. to render a
diff) time out after 60s. Similar time constraints are put onto other
rendering frond-ends. Actually you can easily get Apache to segfault
if you do not
5 matches
Mail list logo
