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