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

[Dean Michael Berris via llvm-dev]

> 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>
>> 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.

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.

Cheers