James <pkx1...@gmail.com> writes: > I don't know the ramifications of running two merges at the same time
None, really. The worst is when the second merge starts from a later version of origin/staging and still finishes first. In that case, the first merge will flag an error when it tries pushing an already superseded master. Alternatively bad is when a merge starts working on some version origin/staging that gets removed/overwritten for a different reason than failing verification. In that case, when the merge finishes, it will push something to master that will not match the changed staging. As a consequence, the automatism comes to a stillstand until the situation has been salvaged by basing staging off the unfortunate master and fixing the problem in staging. But that problem case is not related to multiple instances of merges. > so if you can keep it an hour either side of 18:00 BST to NOT compile > we won't hit each other. We've dumbed down the procedure enough that nothing worse than an error report should be able to happen automatically. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
