[llvm-dev] [RFC] One or many git repositories?
Dean Michael Berris via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 29 23:19:32 PDT 2016
> On 30 Jul 2016, at 00:26, Robinson, Paul <paul.robinson at sony.com> wrote:
>> -----Original Message-----
>> From: llvm-dev [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>
>>> On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com>
>>>> 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.
I tried it for compiler-rt hosted in an LLVM checkout and it works just fine. I can't say for other libraries/tools in LLVM but if it isn't then that's something worth fixing (if that's something that's explicitly supported by the community).
> 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.
Sorry, I wasn't asserting anything, I was conjecturing (if that's even a word).
>> 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 think that's a tenuous analogy -- if I only have to drive to work *once* and then get a new faster and easier to navigate mode of transport once I get there (maybe because the workplace will provide a better way once you've gotten there), then sure, I'll take that trailer and haul some stuff along the way too. :)
> 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.
Sorry, not checkout times -- clone times.
Or did you mean to be using SVN still? In that case then you should still be able to use the per-project mirror on GitHub using the SVN interface.
If you were going to use git, then you clone it once and then 'git pull --rebase upstream master' or something similar.
> 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.
> 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.
I find this too if I do "git svn rebase". What I do today now though is I pull from the git mirrors, then "git svn rebase -l" -- the git pull takes a lot less time, and the local rebase just works like lightning.
Your mileage may vary.
More information about the llvm-dev