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

Proposal to change the semantics of DONTBUILD

2013-01-15 Thread Ehsan Akhgari
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 terminology) when the top-most changeset is