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

[Matthias Braun via lldb-dev]

> On May 31, 2016, at 3:01 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote:
>> 
>>> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
>>>> To be more exact here: I usually do not checkout llvm svn at a higher
>>>> level because that forces me back to svn (which last time I used it did
>>>> not have built-in support for bisection, not sure if that changed
>>>> recently).
>>> 
>>> svn-bisect is a trival tool and should be part of every good svn
>>> installation. While I never got around to script the part of "update all
>>> subrepos to the same revision", it certainly doesn't involve any
>>> addition checks. From what I can tell, git submodules don't even support
>>> that easily. I might be wrong though.
>> 
>> In a nutshell:
>> git-submodules basically records a git revision of your submodules with the commits.
>> You can make such revision switches a natural part of commits.
>> "git submodule update [--recursive]" will bring your submodule checkouts in sync with what the toplevel repository expects.
>> 
>> In any way we can have this discussion separate from the discussion of moving to git. We can stay with our current ways of matching same date for now.
> 
> But the move to git introduces the UI regression in first place. No date
> matching and the like is necessary with subversion.

True to some extend, though I know several people (myself included) that rather use the git-svn inconvenience today simply because git-bisect exists and git being a lot faster at switching revisions than subversion. This tactic also starts failing once you work with custom release branches outside of llvm.org's control.
In principle you could also put the toplevel llvm svn into a git-svn repository to fix the problems and I think there is some repository out there who does that, but IMO that just brings back part of the problem of slow checkouts (a few gigabytes of extra disk space required per checkout as well).

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160531/16570ce0/attachment-0001.html>