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

[Justin Lebar via llvm-dev]

> Which projects do we put under this monolithic repository?

The proposal at the moment is to include

  llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt,
openmp, and parallel-libs.

This is the set {llvm} plus the transitive closure of "projects that
are version-locked to a project in the set", where the closure is
taken over the set of all active LLVM subprojects.

Projects that don't depend on a specific version of llvm or some other
subproject -- test-suite and libc++ -- are not included.  Everything
else is, because the whole idea is to have one repository that
captures the implicit versioning dependencies between (say) lldb and
llvm.

As soon as we have one version-locked subproject that's not in the
monolithic repo, we now we have to maintain an umbrella repo that
tells you which version of llvm corresponds to which version of the
version-locked-but-not-in-monolithic repo.

The cost of including additional projects in the monolithic repository
is very low, since you can ignore them using sparse checkouts.

On Thu, Jul 21, 2016 at 9:49 AM, Renato Golin <renato.golin at linaro.org> wrote:
> Question:
>
> Which projects do we put under this monolithic repository?
>
> SVN has about 42 projects, some of them dead, some of them in life support.
>
> So far, being "an upstream repository" meant being inside the LLVM SVN
> server. We'll change that to "being inside the monolithic LLVM
> repository". But this can become huge, and not all projects "ink" back
> to LLVM.
>
> An alternative would be to just have some core projects in the
> monolithic and everything else as separate, but then what's core?
>
> As a back-of-the-envelope, I suggest: llvm, clang, clang-tools-extra,
> compiler-rt, libc++, libc++abi, libunwind, test-suite.
>
> I'm thinking LLD and LLDB could remain out, but I don't think it would
> be too weird for them to be in...
>
> Anything else? Less?
>
> cheers,
> --renato