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

Tue May 31 13:56:44 PDT 2016

On Tue, May 31, 2016 at 1:23 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'm in favor of both going to git as the source of truth, and then
> switching the hosting to github.
>
> 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.
>
> 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.
>
>

In previous months , I have studied many thousands of Github repositories ,
and cloned many of them locally to compile and run .

The following difficulties may exist during LLVM works :

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 .

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 .

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 .

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 .

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 .

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_" .

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 .

 The most affecting points are the above ones for me as a "visitor user" of
Github repositories .
I do not have any experience as "developer user"  of Github .

Mehmet Erol Sanliturk

> On Tue, May 31, 2016 at 12:31 PM, Renato Golin via cfe-dev <
> cfe-dev at lists.llvm.org> 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
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160531/054ffd2e/attachment.html>