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

Thanks for driving this Renato.  It going to be a huge benefit to everyone once
we have a solution in place.
> On Jul 20, 2016, at 11:03 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> When everyone is happy that we have enough proposals, Tanya's survey
> should be brought forward, in which case I'll gladly offer my help
> again.
Regarding the survey specifically, and since I didn’t see a thread discussing
survey options, I’d love to have a ‘I don’t mind what the solution is, I just
want git’ option.  Basically, ‘any of the above’.

For me, I’m very happy with the proposals being discussed, but mostly just want
to move to a more reliable hosting service (full disclosure, I’m a fan of
GitHub), and I use git-svn anyway so native git would be best for me.

Anyway, not trying to derail the discussion, just express that there are likely
many others like me out there who are silent not because we don’t have an
opinion, but because we just want git and don’t want to have an excessive number
of +1’s on a thread saying so.

Cheers,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/46715e0e/attachment.html>

> Anyway, not trying to derail the discussion, just express that there are
likely many others like me out there who are silent not because we don’t have an
opinion, but because we just want git and don’t want to have an excessive number
of +1’s on a thread saying so.
+1 :-)

There's another reason I've been staying quiet too which is that past
experience with VCS migrations has taught me that people tend to over-value some
things and that discussion tends not to convince people in advance of direct
experience. I think some of these topics will end up being moot once we've
moved to git and gotten used to it. For example, I've seen talk of wanting
to preserve linear history which is understandable since it's quite nice to
have. However, I suspect we'll drop that after a month or so as people find
'git push' doesn't work very well on a high traffic repo and start
looking for alternatives. At that point I think we'll end up switching to
pull requests and accepting non-linear history. Similarly, I think the desire
for incremental revision numbers will gradually fade as people get used to git.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pete
Cooper via llvm-dev
Sent: 21 July 2016 17:46
To: Renato Golin
Cc: LLVM Developers
Subject: Re: [llvm-dev] [RFC] One or many git repositories?

Thanks for driving this Renato.  It going to be a huge benefit to everyone once
we have a solution in place.
On Jul 20, 2016, at 11:03 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

When everyone is happy that we have enough proposals, Tanya's survey
should be brought forward, in which case I'll gladly offer my help
again.
Regarding the survey specifically, and since I didn’t see a thread discussing
survey options, I’d love to have a ‘I don’t mind what the solution is, I just
want git’ option.  Basically, ‘any of the above’.

For me, I’m very happy with the proposals being discussed, but mostly just want
to move to a more reliable hosting service (full disclosure, I’m a fan of
GitHub), and I use git-svn anyway so native git would be best for me.

Anyway, not trying to derail the discussion, just express that there are likely
many others like me out there who are silent not because we don’t have an
opinion, but because we just want git and don’t want to have an excessive number
of +1’s on a thread saying so.

Cheers,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160722/2476f096/attachment.html>

On 22 July 2016 at 11:16, Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:
> There's another reason I've been staying quiet too which is that
past
> experience with VCS migrations has taught me that people tend to over-value
> some things and that discussion tends not to convince people in advance of
> direct experience. I think some of these topics will end up being moot once
> we've moved to git and gotten used to it. For example, I've seen
talk of
> wanting to preserve linear history which is understandable since it's
quite
> nice to have. However, I suspect we'll drop that after a month or so as
> people find 'git push' doesn't work very well on a high traffic
repo and
> start looking for alternatives. At that point I think we'll end up
switching
> to pull requests and accepting non-linear history. Similarly, I think the
> desire for incremental revision numbers will gradually fade as people get
> used to git.
This is valid on a monolithic model, and that is one of the reasons I prefer it.

Today, I personally prefer the Git model (merges, pull requests, fuzzy
history), but I haven't always done so. The more I learnt how to use
Git, the more I realised how valuable the "confusing model" is for
distributed development.

Trying to force Git into an SVN model for the long term feels like
creating a niche that will be hard to work with (no hard evidence,
pinch of salt and all that).

I don't maintain a downstream fork, so I can't speak for that niche.
But forks in GitHub (all, not just LLVM's) seem to be fine merging
their patches over the original repository.

What this feels to me is that we were too complacent with the old
model and were slowly creeping Git support in an SVN world, and now we
realised how unusual is our "requirements".

Maybe you're right. Maybe moving to yet another model that satisfies
those requirements would be a step back, because we'd be setting in
stone a rule that was accommodated, not designed.

Maybe we should propose a third model: Use Git like Git. Pull requests and all.

As a quick recap of the things could go wrong, here's a
back-of-the-envelope idea of what could go wrong...

Changes that are the same as in linear monolithic core with external projects:

* the repositories themselves will have to adapt
* the build system (CMake and all)
* how the non-core repositories interact (relates to build system, bisect)
* all public forks (GitHub and others)
* all downstream forks (Many current LLVM active development affected)

New problems will be created:

* public and downstream forks that *rely* on linear history
* validation (buildbots will have to be re-written, or we'd have to
move to Jenkins, pull-request testing, etc)
* bisection (all our current tools will have to understand Git)
* library dependencies will be hard to bisect, because they won't be
in the same repository with the same history. This happens today in
GNU-land with binutils, glibc, etc.

All in all, not *that* different from the linear monolithic proposal,
and in my opinion, a future facing design, not a past driven
conformance.

cheers,
--renato