Re: [RFC/PATCH 0/3] protocol v2

From: David Lang <david@lang.hm>
Date: Mar 2, 2015, 01:05 UTC
Message-ID: <alpine.DEB.2.02.1503011653000.12474@nftneq.ynat.uz>
In-Reply-To: <CAGZ79kaHGw=OyrkktWeo-MR0V1_bASB1cioP+c2Ngpt6fkRxBA@mail.gmail.com>

On Sun, 1 Mar 2015, Stefan Beller wrote:

Show 19 quoted lines

> The way I understand Junio here is to have predefined points which
> makes it easier to communicate. There are lots of clients and they usually
> want to catch up a different amount of commits, so we need to recompute it
> all the time. The idea is then to compute a small pack from the original point
> to one of these predefined points.
> So a conversion might look like:
> Client: My newest commit is dated 2014-11-17.
> Server: ok here is a pack from 2014-11-17 until 2014-12-01 and then
> I have prepared packs I sent out all the time of 2014-12 and 2015-01
> and 2015-02 and then there will be another custom pack for you describing
> changes of 2015-02-01 until now.
>
> Mind that I choose dates instead of arbitrary sha1 values as I feel
> that explains the
> point better, the packs in between are precomputed because many
> clients need them.
>
> Personally I don't buy that idea, because it produces a lot of question, like
> how large should these packs be? Depending on time or commit counts?

I think this is going to depend on the project in question. I think that doing this based on public tags makes lots of sense. The precomputed packs should also change over time.

For example, with the linux kernel, as each -rc is released, there will be a lot of people wanting to upgrade from a prior -rc, so having a pack for each of these is probably worthwhile. You probably also want a precomputed pack to move from some of the -rc releases to the final release. And then a single pack to move from the prior final release to the newest one. There may also me a resons to make a pack that jumps several releases to go from one LTS kernel to the next.

Exactly what precomputed packs make sense, and how large the packs should be is going to be _very_ dependent on the update patterns of users. The only people who can decide exactly what packs they should use are the admins of the systems, and should be based on their logs of what requests are being made. I can see the git project creating scripts to analyze the logs of client connections to make recommendations on what packs would be useful to have pre-generated, ideally ordered by how much computation they would save (and the amount of disk space required to hold the packs, and then the admin of the site can indicate where they want the cutoff to be. Some extremely busy sites may have a lot of disk space compared to CPU and be willing to have lots of packs around, others are less busy and will only want to keep a few around.

David Lang