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

C Bergström via lldb-dev lldb-dev at lists.llvm.org
Tue May 31 12:49:56 PDT 2016


peanut gallery comments from a git hater (We use git for all source
revision control)

On Wed, Jun 1, 2016 at 3:31 AM, 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.

Are you referring to linear commit history being maintained going
forward or what specifically?

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

Sub modules don't work exactly like svn. afaik they are glued to a
specific commit?
So you get questions like this
http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodules

So if this path is chosen, please make sure the minimum git version
supported is clarified.

>
> 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).

Bugzilla sucks, but github's issue tracker sucks worse (imnsho). I'm
not a stakeholder and have no vote, but if it ain't broke don't fix
it.. or try jira.. (they give free licenses to open source and it
rocks)

>
> 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?

There's already git mirrors of all this stuff on github - *if* you're
going to go down this path, I think the 1st step is updating docs to
ask people to use those as a preferred solution. Based on that
feedback you can wean people off svn instead of hard cut.

This really falls into 2 categories - read-only and write..

For read-only the migration should be straight forward, but write gets
a bit more tricky as you'd need to likely rely on git-svn (which I
suspect some people are already using)

Even though git 1.7 or something deals with submodules better - I
don't personally like them at all. I'd rather have a convenience
script or something which pulls and clones the sources. Not everyone
needs all the sources and then there's the question of all the
subprojects and build.. etc Not changing the workflow here would be
most sane..

So clone llvm ; cd tools / ; clone ...
----------
good luck with this.. I foresee near religious opinions on the horizon..


More information about the lldb-dev mailing list