Dear Renato,
Do you have a set of volunteers lined up to do such a migration? Getting
people willing to do the migration will obviously be key, and that was
the one thing I didn't see in the original email.
Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
perhaps we should just put Clang and LLVM into a single git repository
and add a CMake option to disable compilation of Clang (the same could
be done for other LLVM sub-projects for which bisection and other nifty
features require a single revision number to refer to code across
projects). Keeping these projects in separate repositories is just more
work, and I don't see what we're getting out of that extra effort.
IIRC, Clang was initially separate from LLVM because it significantly
added to the download time and compilation time. I don't think download
time is really a problem anymore, and compilation time can be fixed with
a CMake option.
For what it's worth,
John Criswell
On 5/31/16 2:31 PM, Renato Golin via cfe-dev 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
--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
