[llvm-dev] [cfe-dev] Git Move: GitHub+modules proposal
Frédéric Riss via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 30 08:23:59 PDT 2016
> On Jun 30, 2016, at 1:26 AM, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com> wrote:
>>> That makes it fragile, and that’s why I disagree with your “90% done” assessment.
>>> What if the service behing the hook is down for a few days?
>> In the long-term view, a pretty trivial catch-up script ought to be
>> able to synthesize a sane history after any amount of down-time.
>> People could even run it locally for their bisecting needs if it was
>> that important to them.
> Yup. If the script is stable (as in sort stable), anyone running it
> locally will get the same results as upstream and each other.
>> In the short term, I don't think it's a critical enough service to
>> worry about, frankly. What we already have is hopelessly fragile:
>> right now when LLVM's server plays up it takes out absolutely
>> everything, in the proposed world it would take out this bisecting
>> convenience feature. Seems like a strict improvement to me.
> I think it's even less important than that. Bisecting will work
> *better* when using submodules than it does using SVN (because git
> bisect is more powerful, allows me to track all modules' history, and
> will rid me of a complicated downstream set of SVN-bisect scripts).
> The only thing we *have* to have a sequential number for, are
> releases. Even that can be ran manually.
LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential numbers as commit identifiers.
> We agreed to have sequential numbering from the start to allow
> infrastructure to migrate slowly to a Git model. That can also have an
> extra step to run the script if IDs are not populated yet.
>>> Who will maintain it?
> Whoever maintains the current infrastructure, which is currently the
> Foundation. All scripts will be upstream.
> So far, they (Tanya, Anton, Galina) have been very responsible to
> every downtime and problems I found. I have no doubt that this will
> continue to be a trend.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
More information about the llvm-dev