Re: Proposal to change the semantics of DONTBUILD

2013-01-16 Thread L. David Baron
On Tuesday 2013-01-15 13:20 -0800, Gregory Szorc wrote: > This seems to make sense. My only concern is if there is a scenario > where you absolutely need to push without incurring a build (think > merge commit where you don't have control over the previous > commits). I'm not sure why we'd do that,

Re: Proposal to change the semantics of DONTBUILD

2013-01-15 Thread Ed Morley
On 15/01/2013 23:52, Daniel Holbert wrote: In that scenario (if it exists) you could always use the build API (and the shortcut red-stopsign buttons on TBPL) to effectively get what you want. Killing running builds would mean needing to clobber all machines for all platforms for that tree (unt

Re: Proposal to change the semantics of DONTBUILD

2013-01-15 Thread Daniel Holbert
On 01/15/2013 01:20 PM, Gregory Szorc wrote: > This seems to make sense. My only concern is if there is a scenario > where you absolutely need to push without incurring a build (think merge > commit where you don't have control over the previous commits). I'm not > sure why we'd do that, so I'm inc

Re: Proposal to change the semantics of DONTBUILD

2013-01-15 Thread Gregory Szorc
On 1/15/13 1:11 PM, Ehsan Akhgari wrote: Hi all, Currently, DONTBUILD only takes affect if it's set on the tip of the changesets that you push. This can cause problems when merging between different trees if the target tree is a full subset of the origin tree (i.e., fast-forward merges in git t