See Installer>>#primMerge:.  You may want to do something similar in
the CI scripts.

Then again, isn't CI supposed to tell us when something with the trunk
needs attention?  If something needs merged then it need attention and
CI could/should report on that shouldn't it?

On Fri, Sep 20, 2013 at 6:29 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 17 September 2013 08:40, Frank Shearar <frank.shearar at gmail.com> wrote:
>> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof.
>
> Well, I haven't managed to log updates, but I _have_ finally managed
> to fix the CI update scripts. A merge conflict caused an
> MCMergeBrowser to pop up and halt the world. CI assumed the task had
> hung (which it had, effectively), and hilarity ensued.
>
> http://build.squeak.org/job/SqueakTrunk/532/console shows a properly
> working update. (I have no idea where all those empty lines are coming
> from... unless they're progress indications?? Could be!)
>
> The script didn't just bail because an MCMergeResolutionRequest has a
> #defaultAction (to bring up the dialog). Since the script doesn't
> catch that exception, the #defaultAction triggers, popping up the
> dialog.
>
> Without having thought it through, one possible solution is to _never_
> create dialogs directly, but always through ToolSet. (So Monticello
> would extend ToolSet's API, for instance.) That way, a
> CommandLineToolSet could bail with a decent error message, while (in
> this case) the StandardToolSet could pop up a MCMergeBrowser.
>
> frank