<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 1:23 PM, Reid Kleckner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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"><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></blockquote><div><br><br><br><br></div><div>In previous months , I have studied many thousands of Github repositories , and cloned many of them locally to compile and run .<br><br><br></div><div>The following difficulties may exist during LLVM works :<br><br><br></div><div>If a directory contains large number ( approximately more than thousand ) of files , only a part of these files are displayed and others are not allowed to view . You may check this from OS repositories .<br><br><br></div><div>During cloning , if there is a reference to another repository , clone --recursive are giving errors about contained @ sign . In that case it is necessary to enter into sub-directories and manually clone that referenced sub-module ( or a script should do this ) . Instead of --recursive , the other statements may be used , but all of them have advantages/disadvantages . <br><br><br></div><div>When "Download" is selected for repository , sub-modules are not downloaded into respective sub-directories . It is necessary to visit such directories manually one by one and download , expand , and adjust these directory contents .<br><br><br></div><div>When a file is viewed in Github and returned back , Github is switching to the top of the directory , not aligning the page at the current cursor position . When there are large number of files in a directory , it is causing difficulty to go down to the current cursor position  again and continue from there . <br><br><br></div><div>A limited kind and size of files are shown to the user . There are many kinds that it is possible to only viewing the content is to save repository locally . To my experience , any single file in a repository directory is not permitted to download to view it in that case .<br><br><br></div><div>I consider revision numbers as only a disastrous design : A very long number conveying nothing other than inconvenience . Therefore it will not be possible to specify "revert to _a_simple_number_"  elegantly . I do not know what will be shown to say "revert to _a_cryptic_number_" .<br><br><br></div><div>Previously it was possible to search Github for repositories on supplied keywords . Now , they have disabled that feature . Now , it seems only Internet searches may find a repository ( to my experience , only very few of them are found ) , or it may be listed in their category lists to find only ones selected by Github .<br></div><div><br><br></div><div> The most affecting points are the above ones for me as a "visitor user" of Github repositories .<br></div><div>I do not have any experience as "developer user"  of Github .<br><br><br></div><div>Mehmet Erol Sanliturk<br></div><div><br></div><div><br><br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><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" target="_blank">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>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>