[cfe-dev] Maintaining a clang fork

[Robinson, Paul via cfe-dev]

> On 03/10/2016 12:42 PM, Hal Finkel via cfe-dev wrote:
> > ----- Original Message -----
> >> From: "Nat! via cfe-dev" <cfe-dev at lists.llvm.org>
> >> To: cfe-dev at lists.llvm.org
> >> Sent: Thursday, March 10, 2016 10:41:59 AM
> >> Subject: [cfe-dev] Maintaining a clang fork
> >>
> >> Hi
> >>
> >> I am just wondering if anyone has experiences maintaining a clang
> >> fork
> >> and how you do it ?
> >>
> >> It wasn't very easy for me to move from 3.7 to 3.8, since there were
> >> about 2000 commits I had to merge. git wasn't too clever with the
> >> merge
> >> either, finding stuff to merge in files I had never touched. In the
> >> end
> >> I reversed my mode of operation, and merged into master from my
> >> branch,
> >> using -strategy ours to keep mainline intact and preferred to reedit
> >> many of my changes.
> >>
> >> It would appear advantageous to have some sort of continous
> >> integration,
> >> where each commit from mainline is automatically merged into my
> >> branch
> >> and then a compile is attempted. If things break, the integration
> >> stops.
> >> Otherwise it just keeps on churning. If this makes things really
> >> easier
> >> though, I don't know. Does this exist ?
> > When I've done this I've had scripts that do a nightly pull/merge
> followed by a build and test. If any of that fails, I'd get an e-mail. In
> my experience, doing this between 3-4am central time works best.
> We have an automated script which runs twice a day and does an automated
> pull/merge/test.  If everything succeeds, it directly pushes into our
> local tree.  We've found this succeeds roughly 50% of the time and that
> the rest need (mostly minor) hand resolution. I'd generally say that a
> faster merge interval leads to less pain overall.

How often you'll run into a problem depends on (a) what you've changed,
and (b) what other people upstream are working on.  We're experimenting
with a continual-merge bot and observing conflicts 2-3 times a week.
(No hard data on frequency of test failures, that's next on the list.)

Philip is doing things that are much more invasive (from what he's said)
than we do, so I'm not surprised he sees something essentially every day.
--paulr