[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo

[Bruce Hoult via llvm-dev]

Furthermore ... I don't think the occasional failure in the past to do
atomic commits for things that should have been (i.e. the initial commit to
one project breaks things until the following commit to another project is
made) means that there is no value to doing atomic commits in the future.

The same applies to having some kind of pre-commit testing in future.

I've previously posted the results of something I did about a year ago,
attempting to compile clang and run basic tests (build and run HelloWorld
on x86_64) on all 80000 or so revisions from 3.6 until the end of October
2017. Using these criteria I found 649 bad commits (0.76%) in 309 runs.

This is low, but it's enough to seriously affect bisection or incremental
rebasing (e.g. using git-imerge) unless you have a database of which
commits to ignore.

http://lists.llvm.org/pipermail/llvm-dev/2018-October/126970.html

On Mon, Nov 19, 2018 at 7:27 AM Dean Michael Berris <dean.berris at gmail.com>
wrote:

>
>
> > On 16 Nov 2018, at 11:46, Tim Northover via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On Fri, 16 Nov 2018 at 00:43, Tim Northover <t.p.northover at gmail.com>
> wrote:
> >> I've also encountered many non-synced commits when bisecting myself.
> >
> > Sorry, this was wildly misstated (i.e. wrong). I don't recall ever
> > being stung by a mismatched commit (beyond having to checkout a
> > vaguely similar revision to compile).
> >
> > I still think the atomicity has very limited use in practice.
> >
>
> As someone who’s needed to work on features that span all three of clang,
> llvm, and compiler-rt on a regular basis, I would respectfully disagree.
> The need for atomic commits across these projects for XRay has been there
> since the beginning of the effort (sometime 2016), and we’ve been relying
> on this using the helper scripts on top of the prototype monorepo since
> it’s been a thing in the latter half of 2017.
>
> We’ve broken XRay across clang, llvm, and compiler-rt a while back and
> have had to revert and re-apply changes across projects leading to the
> repository being in intermediately broken states. I’m positive that other
> projects that rely on doing similar kinds of changes can vouch for the
> massive convenience that having atomic commits across projects on a
> day-to-day development and code archaeology.
>
> I’m happy to provide more specific details if necessary, but so far, just
> in the past few weeks I’ve been making cross-cutting atomic changes
> spanning llvm+compiler-rt (can be seen in the subversion history as well)
> using the prototype monorepo and the script(s) to do ‘git llvm push’ to do
> the translation from a commit in git into a single commit in subversion.
> This is, IMO, the key “killer feature” of having a monorepo and atomic,
> version-locked, cross-project changes brings to projects like XRay that
> span multiple LLVM projects. I can easily see this being the case for the
> sanitisers, lld, libcxx, clang, and potentially any combination of the
> projects in the monorepo.
>
> Cheers
>
> -- Dean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181119/9897c3ba/attachment.html>