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

[C Bergström via llvm-dev]

On Thu, Jul 28, 2016 at 3:36 PM, David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi James,
>
> I don’t agree that it holds none of the advantages.  LLVM components are, broadly speaking, in two categories:
>
> - Those that are tightly coupled to others
> - Those that are not
>
> Pulling the LLVM Support library out of the LLVM repository, for example, would not make sense because (even though it can be built stand-alone and doesn’t depend on the rest of LLVM) it is tightly coupled to other things and someone who changes it may need to atomically update the other LLVM libraries and possibly projects such as clang to conform to the new APIs.
>
> Similarly, lldb, lld, and clang are all dependent on unstable APIs in LLVM (and lldb on unstable APIs in clang).  We therefore need to either retain the ability to update these consistently.  This gives us three choices:
>
> 1) Put LLVM, lldb, lld and clang all into the same repository.
>
> 2) Make LLVM a submodule of clang and lld, and clang a submodule of lld so that any API-breaking change doesn’t get propagated into the projects that depend on them until the consumers of the APIs have also been updated

I don't agree that you need submodules or bundling in order to achieve
this. Lots of projects for decades have worked just fine without doing
either of these. Solaris kernel and libc are pretty tightly dependent
on each other, but existed in separate repo.

Part of how they overcame this was frequent tags which acted as sync points.

binutils and glibc also have dependencies and compatibly requirements,
but they shouldn't be bundled, should they?

I'm strongly opposed to bundling and monolithic design, but it's
likely idiot proof.
--------------------------
One thing to keep in mind - it's easier to bundle than it is to
unbundle. The migration could start with 500 git projects all without
submodules and as people hit real world problems, things can be
incrementally fixed. It seems like everyone is trying to boil the
ocean in advance.

It's somewhat funny and ironic that when it comes to API design and
some compiler internal planning people play kick the can, but when it
comes to something like git vs svn or other things dealing with infra
everyone is an expert and willing to post and post and post to the
same thread..