[LLVMdev] svn mirror git?

[Chandler Carruth]

On Fri, Nov 16, 2012 at 1:53 PM, Greg Fitzgerald <garious at gmail.com> wrote:
> My interpretations, which later in this long email, I'll assume as
> premises to a recommended action:
>
> * Chris finds code reviewers to be exceptionally rare and the
> community's most valuable participants.  My previous "spork"
> suggestion would be a decision made my maintainers, not influenced by
> patch-contributors, and would only happen if the maintainers felt the
> transition made it easier for them to review and/or commit patches.
>
> * Dropping SVN would be expensive for some.  Instead of dropping SVN,
> it is more reasonable to make git the central repo and have SVN mirror
> git.
>
> * A linear history is highly valued by Chris and many members of the community.

You missed what is (IMO) the most important point: LLVM's development
process and VCS optimize for active developers working in the open on
mainline LLVM. They don't optimize for private forks or other
development processes. This isn't an accident, and it helps
incentivize members of the community to contribute early and in small,
incremental patches.

> Changing the ID creates
> a serious problem, one which forces the private fork to make an early
> decision about contributing back to the community.

The fact that this (and all of the related and restated problems you
and others have outlined since this email) is predicated on a private
fork is why it isn't a priority for the process. If you instead make
the early decision to contribute small, incremental patches, then this
is not a problem.

I'm not claiming it is not a problem as a hypothetical claim which I
haven't tested. There are numerous groups (including mine) working
with LLVM without any problem due to this. There are even several that
*do* have some code which doesn't go upstream, and they also are not
thwarted by this.

<snip>

> Proposal: a slow, multistep, backward-compatible transition to remove
> the disincentive to contribute patches from private forks:

I strongly doubt that this is the primary barrier for the contribution
of such patches. Code review, the fact that these patches have
accreted for long periods of time outside the view of the community,
and a lack (or broken nature) of incremental development processes
seem likely to cost much more.

> P.S. tl;dr, right?

Actually, yes. This entire conversation is too long to read.

Many are claiming there is something wrong with the use of Subversion.
And yet, despite these "problems", LLVM and Clang are among the
fastest growing and most active open source projects I have had the
pleasure of working on. Also, the most active members of the community
(who should be hitting these problems the most often) are never the
ones crying for change. I suggest folks instead work to demonstrate
the scaling problems of Subversion by contributing ever more rapidly
to LLVM. Perhaps we will discover the problem, but either way LLVM
will improve by leaps and bounds. ;] Everybody wins.