llvm dev - Jun 2016 - Git Move: GitHub+modules proposal

On 27 June 2016 at 15:39, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to
I don't think the consensus was to change the order of inclusion (llvm
into clang), but to *not* change anything else at this stage.

That's one of the reasons the umbrella project with sub-modules was
the most accepted solution, because we can later change the inclusion
order (if we all agree, etc), without changing the underlying storage.

> * Change llvm.
> * Change clang and in the same atomic commit change what revision the
> submodule points to.
Having one repository inside another was rejected due to the problems
it brings for development, validation and release. James has just
pointed a few of those problems for development.

An umbrella project with a commit hook and an auto-update would make
sure all commits are synchronised correctly. Though, indeed, this will
mean we'll still have the trouble of buildbots picking up one commit
and not the other, I don't think this is a big enough problem that we
should mess up everyone's workflow.

cheers,
--renato

I think that trying to create a ordering/rev number between independent git
repositories is fundamentally unreliable.

If we want to keep llvm and clang in lock step we should probably probably
just have them in the same repository like
https://github.com/llvm-project/llvm-project.

Cheers,
Rafael
On Jun 27, 2016 11:10 AM, "Renato Golin" <renato.golin at
linaro.org> wrote:
> On 27 June 2016 at 15:39, Rafael Espíndola <rafael.espindola at
gmail.com>
> wrote:
> > So, I probably missed something, but what was the main objection to
> > just using submodules? This would put llvm inside clang instead of the
> > other way around. When changing an API one currently has to
>
> I don't think the consensus was to change the order of inclusion (llvm
> into clang), but to *not* change anything else at this stage.
>
> That's one of the reasons the umbrella project with sub-modules was
> the most accepted solution, because we can later change the inclusion
> order (if we all agree, etc), without changing the underlying storage.
>
>
> > * Change llvm.
> > * Change clang and in the same atomic commit change what revision the
> > submodule points to.
>
> Having one repository inside another was rejected due to the problems
> it brings for development, validation and release. James has just
> pointed a few of those problems for development.
>
> An umbrella project with a commit hook and an auto-update would make
> sure all commits are synchronised correctly. Though, indeed, this will
> mean we'll still have the trouble of buildbots picking up one commit
> and not the other, I don't think this is a big enough problem that we
> should mess up everyone's workflow.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160627/f9cc868e/attachment.html>

On 27 June 2016 at 17:03, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> I think that trying to create a ordering/rev number between independent git
> repositories is fundamentally unreliable.
>
> If we want to keep llvm and clang in lock step we should probably probably
> just have them in the same repository like
> https://github.com/llvm-project/llvm-project.
That is similar to the proposal we have, except that llvm-projects
will have sub-modules.

Having all of them in the same physical repository is a big problems
for those that only use a small subset of the components, which is the
vast majority of users, most of the time (all buildbots, Jenkins,
local development, downstream users, even releases don't clone all
repos).

cheers,
--renato