(As a downstream user and very infrequent committer) +1 for a move to GitHub. I'm indifferent about git, but pull requests significantly reduce the effort of contributing small patches. I've found I'm much more likely to submit a patch to a project if it is on GitHub.
On Tue, May 31, 2016 at 1:31 PM, Renato Golin via llvm-dev < llvm-...@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/ > _______________________________________________ > 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
