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

[Renato Golin via llvm-dev]

On 25 July 2016 at 17:54, Justin Lebar via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> To re-focus this thread on its original topic: It sounds to me like,
> broadly speaking, we have consensus on using a single repository.

In this thread, yes. :)

Can you write up a document on docs/Proposals and add a review?

I think the survey should be about both of them, and allow people to
digress. I'm willing to take the time to read all of them and try to
collate a "big-picture", but I'd appreciate if others could help me.
:)

I don't think we'll ever get *consensus* on any email thread, as
people do digress too much.


> 1) Should the repository have "unified history"?  (Meaning, should I
> be able to check out a single git revision from before the migration
> and have it contain all of the llvm subprojects?)

Yes.

Every VCS migration I've been involved so far involved doing this, as
it makes it much easier to deal with comparisons between new and old.
Applying patches, trying benchmarks, etc. all become much easier if
you use a single tool / source to checkout from.


> 2) Should the monorepo have a "nested" repository layout (e.g. clang
> goes in /tools/clang) or a "flat" layout (clang goes in /clang)?

Slight preference to nested, but I don't mind either way.

We internally checkout separate and create the worktrees as nested, so
nested is slightly better for us.


> 3) Assuming we want unified history, should the new canonical
> repository's hashes be based on
> https://github.com/llvm-project/llvm-project, or should it start
> afresh?

Fresh, please.

https://github.com/joker-eph/llvm-unified

That one seems good, nested or not, but I'm not sure about polly.
Maybe OpenMP (like parallel-libs?).

cheers,
--renato