[PATCH] D24167: Moving to GitHub - Unified Proposal

[Duncan P. N. Exon Smith via llvm-commits]

> On 2016-Oct-12, at 14:54, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
>>> + * Some concerns have been raised that having a single repository would be an
>>> +   overhead for those that have interest in only a single repository. This is
>>> +   addressed by keeping the single-subproject Git mirrors for each project just
>>> +   as we do today. For contributors that need read/write access the
>>> +   :ref:`GitHub SVN bridge <git-svn-mirror>`  allows to contribute to a single
>>> +   sub-project the same way as today.
>> 
>> Let me try again to reword this, since it's a little awkward.
>> - I'll use "overhead" instead of "burden".
>> - I understand your point about eliding the Git mirror with the SVN bridge.
> 
> There are two classes of users:
> 
> - one is the folks that develop libcxx
> - the other is the people downstream that just integrate libcxx.
> 
> Only the first class needs commit access, so the concern here does not apply to the second class.
> The distinction is important because If we quantify “how many users” are affected by this, in the past Chris was adding the second class as well.
> 
> You reworded paragraph is not spelling it out clearly enough. What about:
> 
> * Using the monolithic repository may add overhead for those contributing to a
>   standalone subproject, particularly on runtimes like libcxx and compiler-rt
>   that don't rely on LLVM; currently, a fresh clone of libcxx is only 15MB (vs.
>   1GB for the monorepo), and the commit rate of LLVM may cause more frequent 
>   `git push` collisions when upstreaming. Affected contributors can continue to
>   use the SVN bridge or the single-subproject Git mirrors with git-svn for
>   read-write. Note that this is not a concern for downstream consumers that
>   don't need commit access.

Your wording makes it sounds like downstream consumers that don't need commit access should ignore the whole bullet.  That's not true, if they care about the size of their checkout.

Maybe you can split this up to satisfy both of us and keep it clear?

    * Using the monolithic repository may add overhead for those *contributing* to a standalone subproject.... (something very similar to one of my wordings)

    * Using the monolithic repository may add overhead for those *integrating* a standalone subproject, even if they aren't contributing to it, due to the same disk space concern as the point above.  Affected users can rely on the single-subproject Git mirrors.