[llvm-dev] [cfe-dev] GitHub anyone?

[John Criswell via llvm-dev]

Dear Renato,

Do you have a set of volunteers lined up to do such a migration? Getting 
people willing to do the migration will obviously be key, and that was 
the one thing I didn't see in the original email.

Regarding the issue of git sub-modules and keeping Clang/LLVM in sync, 
perhaps we should just put Clang and LLVM into a single git repository 
and add a CMake option to disable compilation of Clang (the same could 
be done for other LLVM sub-projects for which bisection and other nifty 
features require a single revision number to refer to code across 
projects).  Keeping these projects in separate repositories is just more 
work, and I don't see what we're getting out of that extra effort.

IIRC, Clang was initially separate from LLVM because it significantly 
added to the download time and compilation time.  I don't think download 
time is really a problem anymore, and compilation time can be fixed with 
a CMake option.

For what it's worth,

John Criswell

On 5/31/16 2:31 PM, Renato Golin via cfe-dev wrote:
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.
>
> TL;DR: GitHub + git submodules [1] could replace all the functionality
> we have currently with SVN.
>
> (also GitLab, BitBucketc, etc).
>
> Here are some of the arguments made on IRC...
>
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.
>
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.
>
> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.
>
> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
>
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).
>
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
>
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/<prj>) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
>
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
>
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?
>
> cheers,
> --renato
>
>
> [1]https://git-scm.com/book/en/v2/Git-Tools-Submodules
> [2]https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
> [3]https://help.github.com/articles/support-for-subversion-clients/
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell