[llvm-dev] Git Transition status?

Tue Jan 17 07:25:33 PST 2017

No. Utterly different to submodules.

Submodules means that every component is in its own repo, and someone who
wants to use all the components has to check out the master repo and then
regularly update not only the master repo but all the submodules, Then,
worse, if they want to commit a change that touches several submodules they
have to do individual commits to each submodule, update their master module
checkout to incorporate those commits, and then make a commit of the new
master module state.

It's an *awful* workflow compared to making your changes that touch
whatever is needed, and then making one commit.

What I'm talking about is akin to the current situation, with a master svn
repo, and automated processes that copy each commit there to both an
all-in-one git repo and to a git repo just for that submodule. These mirror
git repos are read-only to everything except the mirroring process.

The only difference is that the all-in-one git repo will become the master
repo -- there will be no svn repo.

On Tue, Jan 17, 2017 at 6:09 PM, Alexander Benikowski <
sebal007 at googlemail.com> wrote:

> Some infrastructure is needed for this, but it's easy and automated
>
> Well sounds like Submodules to me. Hasn't there been a discussion about it
> in one of the first Gitposts?
>
> 2017-01-17 12:31 GMT+01:00 Bruce Hoult via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> "The people most impacted by mono-repo are those who want to build just
>> compiler-rt"
>>
>> Perhaps more accurate to say "Those who want to contribute only to
>> compiler-rt"?
>>
>> Those who only want to build compiler-rt can check it out from a slave
>> repo that mirrors commits to compiler-rt in the mono-repo. Some
>> infrastructure is needed for this, but it's easy and automated.
>>
>> On Tue, Jan 17, 2017 at 4:17 AM, Chris Lattner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On Jan 13, 2017, at 1:37 PM, Mehdi Amini via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> The main outcome of the BoF had the dev meeting was that we agree’d that
>>> moving to GitHub was the best choice forward for LLVM (IIRC only one person
>>> in the room expressed concerned about GitHub, but he said he had personal
>>> grief with them and nothing specific for LLVM).
>>>
>>> The unknown that remains is: will we use a mono-repo or a multi-repo. On
>>> this aspect:
>>>
>>> - We got consensus at the BoF that downstream users (i.e.
>>> non-contributors) are not impacted by this choice, and we’re not gonna
>>> optimize the repository structure for them.
>>> - My reading of the survey is that the monorepo has a significant lead.
>>> - My understanding of the dynamic of the discussions and question during
>>> the BoF is that monorepo has a significant lead, is likely to satisfy more
>>> people, and has a very small number of people concerned about it. On the
>>> other hand many people have strong feeling about the multirepo.
>>>
>>>
>>> FWIW, I have spoken to a large number of people about the mono vs
>>> multi-repo tradeoffs, and I’m personally convinced that mono repo is the
>>> way to go.  For a few reasons:
>>>
>>> - Monorepo is the “natural” way to use git.  Submodules are possible to
>>> use, but add significant complexity.
>>> - 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).
>>> - 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.
>>> - 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).
>>>
>>> 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.
>>>
>>> -Chris
>>>
>>>
>>>
>>> Considering all the current tradeoffs, it is likely that we will move-on
>>> with a monorepo, even if there are no guarantee or decision made at this
>>> point.
>>>
>>> The path forward (already engaged) is to engage a prototype phase: we’re
>>> building a monorepo and trying to make it usable as much as possible,
>>> without making any change or building anything that would commit us to a
>>> monorepo (for instance we’re not gonna migrate any bots to it).
>>>
>>> The goal of this prototype is that developers can start using a monorepo
>>> to try it, and we can evaluate how it plays in practice, outside of
>>> theoretical considerations. If anyone finds concerns about a given
>>> workflow, we can study what can be improved to address it, or maybe we’ll
>>> hit a wall that would show that monorepo can’t address what we think it
>>> will.
>>>
>>> At some point, if the experiment is conclusive, we should be able to
>>> build a larger majority and hopefully reach a consensus that the proposed
>>> prototype can be considered viable for development and start planning the
>>> actual committing changes.
>>>
>>> The monorepo is not totally ready yet, but you can already experience it
>>> (I live on day-to-day for my development, and a few other people as well),
>>> instructions are in the doc: http://llvm.org/docs/Gett
>>> ingStarted.html#for-developers-to-work-with-a-git-monorepo
>>>
>>> I don’t have any schedule to announce, hopefully we can make it all
>>> happen in 2017.
>>>
>>> Best,
>>>
>>> —
>>> Mehdi
>>>
>>>
>>> On Jan 13, 2017, at 1:07 PM, Keane, Erich via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> Hi all-
>>> I was wondering if anyone knew what the status/schedule of the SVN to
>>> git/github transition was?  I thought I saw that at the November meeting it
>>> was agreed upon, but I'm not sure I saw any progress since?
>>>
>>> Thanks,
>>> Erich
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/9d6e86fd/attachment.html>