RFR(XS): 8145828: JPRT hotspot push jobs should allow merge on push

[David Holmes]

This may be too late but I'd prefer to see an explicit:

# Allow concurrent changes to be merged in prior to pushing
jprt.sync.push=true

both so that:

a) it is visible that this happens and we can control it; and
b) because "sync" is misleading - we always "sync" ie pull in any new 
changes, but what we don't do is merge if there is a conflict with those 
changes.

Thanks,
David

On 19/12/2015 8:20 AM, Mikael Vidstedt wrote:
>
> Please review this small change which relaxes the check made in JPRT at
> the time when a hotspot push job has finished successfully, and the
> changes are about to be pushed.
>
> Currently the job will be marked as failed if a merge is needed, even if
> an automatic merge would complete successfully. This "safety mechanism"
> was reasonable when all pushes were made using JPRT, but since we
> started allowing direct pushes the failure rate has gone up. The
> assumption here is that the code changes will very rarely overlap, and
> even more rarely conflict, so if the automatic merge is successful then
> it's highly likely that the resulting code would (also) pass the JPRT
> testing.
>
> This change enables the automatic merge to be attempted, and if it is
> successful the resulting changes will be pushed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145828
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8145828/webrev.00/webrev/
>
> Cheers,
> Mikael
>