[llvm-dev] [RFC] One or many git repositories?

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 29 10:06:55 PDT 2016

> On Jul 29, 2016, at 7:26 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Dean
>> Michael Berris via llvm-dev
>> Sent: Friday, July 29, 2016 5:04 AM
>> To: David Chisnall
>> Cc: LLVM Developers; Bruce Hoult
>> Subject: Re: [llvm-dev] [RFC] One or many git repositories?
>>> On 29 Jul 2016, at 21:58, David Chisnall <david.chisnall at cl.cam.ac.uk>
>> wrote:
>>> On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com>
>> wrote:
>>>> I understand this, but why isn't "the repo you're interested in" just
>> the megarepo (or monorepo) where every LLVM project resides?
>>> Your assumption is a downstream user of LLVM.  As previously pointed
>> out, we have downstream users of libc++ and the sanitizer runtimes who
>> compile with gcc.  For a downstream user of LLVM, the cost of getting
>> everything else is in the noise.  For a downstream user of libc++ who may
>> want to contribute upstream, the overhead is huge.
>> Even then, are we seriously ignoring the fact that even if you did clone
>> the whole repository including everything, that you can still build just
>> the libc++ and sanitiser runtimes if you wanted to?
> Is it that easy to build a subset of a large checked-out tree?  I haven't
> tried it but my impression is: not so much.

If the layout is flat, what difficulty do you expect compared to today’s situation?

>  Certainly the advertised
> tactics for configuring/building don't tell you how to do that.  Somebody
> figuring out what it takes would be very constructive here, instead of
> just asserting it can't possibly be that hard.
>> Why is this "noise" of
>> any importance to the users who get what they want and then some?
> You want to drive to work? Here, have this semi-trailer; everything
> you want and then some.
> I believe David Chisnall up-thread cited a difference in checkout times
> on the order of a handful of seconds versus a couple of minutes.  While
> naively it might seem not a big deal, over time and depending on what you
> are trying to do yes it can be a big burden.

There are still the read-only views, and the shallow clones that address non-commiters cases.
For commiters, this is a one time cost, I have some difficulty to consider this seriously a “burden”.

> For example right now I have a glitch somewhere in my merge process.
> It's taking an extra 10-12 seconds longer to do something than I think
> it should, per commit.  NBD right?  Except when you're 100 commits behind
> and trying to catch up, now you're talking about >15 minutes wasted.

I don’t really understand what you’re talking about, but for downstream with complex integration (like we do), a single monorepo should be an important simplification of the process.
(Otherwise you can still integrate for the read-only repos anyway).


> Again in the grand scheme of things 15 minutes doesn't seem like much
> but it seriously affects my productivity; it's actually hard to come up
> with tasks that small that I can context-switch to and back easily.
> Interruptions like that really are bad for your ability to concentrate
> on the intellectual task of getting your patch to work.
> --paulr
>> I know some people use only numbered releases of LLVM and the projects.
>> They can keep using those as long as LLVM provides them.
>> Is it really impossible to just build non-LLVM dependent versions of
>> libc++ or the sanitiser runtimes if they reside in one git megarepo?
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/e9365dd0/attachment.html>

More information about the llvm-dev mailing list