On Tue, May 31, 2016 at 1:23 PM, Reid Kleckner via llvm-dev < llvm-...@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-...@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-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
