[llvm-dev] Git Transition status?

Tue Jan 17 08:11:30 PST 2017

> On Jan 17, 2017, at 7:24 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 17 Jan 2017, at 01:17, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> - Monorepo is the “natural” way to use git.  Submodules are possible to use, but add significant complexity.
> 
> Having used submodules in a couple of projects, I’ve not found them to cause more difficulty than they avoided; however, they do have an issue specifically with GitHub, which is that tarballs don’t include submodules so packages are slightly harder to construct (they must point to two releases).

Another one is the future possibility of “pull request”, which is annoying to get across repository.

> 
>> - The download size of a mono-repo is manageable, and seems scalable for a project the size of LLVM (including reasonable growth over the next 10 years).
> 
> The download size of a mono-repo is fine for anyone who would be checking out LLVM today.  compiler-rt and libc++ are both useful without any of the rest of LLVM and contributors to libc++ rarely check out anything more than libc++ (perhaps libc++abi) today.
> 
>> - As Medhi says, according to surveys and discussions in forums like the LLVM Dev Meeting BoF, most people who care are in favor of mono-repo.
> 
> From the online surveys, I think the split was roughly 50:50.

I don’t know on what data you’re basis this on. I looked very closely and here are two questions that contradicts your view.

Question: “If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project?”
-> 55 to 36 in favor of the mono-repo

Question: "Assuming mono-repo gets adopted, how do you plan to contribute?”
-> Only 11% were saying before the BoF that they will continue to use split repository (through git-svn, as today), 86% will use the mono-repo.

>  I’d be very hesitant to regard anything at a BoF as representative of the wider community, as the set of people who have the time and funding to attend a conference is quite distinct from the wider community (particularly for the US DevMeeting, which is right in the middle of university term times).  We’ve made this mistake in FreeBSD before.

I believe it representative enough of the people contributing to LLVM that have an opinion on the question. It obviously can’t be *all* of them in the same room, but with over 400 attendees, the conference seems like a valid signal to me. Especially many of the people that have been very active on this issue were in the room.

>> - The people most impacted by mono-repo are those who want to build just compiler-rt.  We want these people to be happy, but they are very few in number, and their benefit needs to be balanced against the benefit for the larger community that builds llvm (and typically clang or another front end).
> 
> I believe that the big win for the monorepo is the ability to bisect usefully.  It’s currently very difficult to bisect clang, because you can’t bisect clang and llvm independently (LLVM API changes frequently break clang) and they’re in different git repos (or non-enclosing svn subtrees) and so it needs some manual intervention.  Having them in the same repo would ensure that they are in sync and make bisecting trivial.
> 
> In contrast, there is not (and should not be) tight coupling between LLVM and libc++, libunwind, libc++abi, and compiler-rt.  There *may* be ordering requirements (e.g. revision X of libc++ requires c++17 features of revision Y of clang for c++17 features to work), but it is incredibly valuable to bisect these independently to find whether a particular change is a new compiler bug, a new library bug, or an old library bug that is triggered by new compiler behaviour (or an old compiler bug that is triggered by new code).
> 
> I would be in favour of a monorepo for everything that links against LLVM libraries and everything else being in separate repos.
> 
>> Overall, it seems clear that either approach could work, but mono seems to win out because it is more popular and more simple. It would require tweaks to LLVM’s cmake system though: instead of deciding to build a subproject based on whether it is checked out, it should instead be based on configuration time flags.
> 
> I believe that most of this works already - you can opt out of building components that are checked out.

Actually you have to opt-in instead of opt-out right now, and I encourage you to try it if you’re contributing to LLVM: http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo <http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo>

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/fcf9fac0/attachment.html>