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

[Renato Golin via llvm-dev]

On 22 July 2016 at 13:40, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> I don't see it as a step backwards but rather as a way of making people
> comfortable with the switch. I think opinions may gradually shift towards
> a more conventional git model after the switch but that doesn't necessarily
> detract from the value of a more svn-ish model if having one helps people
> switch.

The original idea was to change one thing at a time. SVN to Git, keep
everything else the same.

But that has proven harder than we imagined. So, maybe the best way
forward is not to do one step at a time, but to understand where we
are and what we need and take the "right" (tm) step forwards. Even if
it requires multiple steps, we can combine them into larger, fewer
steps.


>> * public and downstream forks that *rely* on linear history
>
> Do you have an example in mind? I'd expect them to rely on each 'master' being
> an improvement on 'master^'. I wouldn't expect them to be interested in how
> 'master^' became 'master'.

Paul Robinson was outlining some of the issues he had with git
history. I don't know their setup, so I'll let him describe the issues
(or he may have done so already in some thread, but I haven't read it
all).


> Assuming the goal is to preserve what we have rather than improve it, buildbot
> will be fine without any changes (beyond switching the source steps from svn to
> git of course) whichever model we pick. It would just check out the latest 'master'
> on each build like it currently does for trunk.

I meant Zorg and the like. Buildbot itself can handle Git, but we may
have assumptions that the repos are linked and linear in the builders.

But we have been discussing pre-commit testing for a while and it's
clear that Buildbots, in the way they're setup now, are not the
answer.

For the sake of the argument, here is the list of things we found:
 * buildbots can have pre-commit testing via patch submission, but
controlling security and load is not trivial if we want people to
actually use it
 * buildbots tracking non-master branches have the load problems if we
allow people to create branches, but not the security problems
 * having a mirror so that bots track that mirror would solve the
security and load problems, but remove the ability for other people to
use it.

In essence, buildbots are single purpose and hard to configure (much
of it needs master restart).

OTOH, Jenkins can have configurable build scripts, with parameters and
customisations, that allow for us to pick pull requests and build
them, as they come.

It also scales independently, per architecture, from the number of
configurations, if you can use something like containers. So, in the
long term, it's cheaper and more robust to maintain.

However, it's a big change and will require another massive change in
how we do things, and the repository is already big enough.

cheers,
--renato