Strategies for push/merge problem?

[Adrian Buehlmann]

On 15.07.2008 14:50, Douglas Philips wrote:
> On 2008 Jul 15, at 8:31 AM, Adrian Buehlmann wrote:
> 
>> On 15.07.2008 13:46, Paul Moore wrote:
>>> As a particular case, a release repository cannot enforce an "all
>>> revisions must pass the test suite" policy, because the individual
>>> work-in-progress changesets remain visible. But an "all revisions
>>> which were tip" (needs a better description) must pass the test  
>>> suite"
>>> policy is viable - as long as those revisions are easy enough to
>>> discover/list.
>> Not sure what you are talking about here.
>>
>> Are you talking about deliberately committing states of the tree
>> that fail the testsuite? Committing such states is bad.
> 
> No, that is just one point of view. I love that commits are cheap and  
> fast. It means I can have several "fallback" positions to which I can  
> retreat and take off in a different direction. commit != push.

That doesn't mean your commits are allowed to break the tests.

"Cheap" commits doesn't mean they are allowed to be brain damaged.

>> Having piles of changesets which break tests is really bad for
>> bisecting.
> 
> Sounds like you want to have intermediate commits collapsed before  
> they are pushed.

Not at all. I just wouldn't want to see your test suite breaking
odyssey in the central repo, if we would ever happen to work on the
same project.

> That is certainly one policy. Another policy is that
> a set of changesets which are pushed together should not fail the  
> testsuite.

Pushing is an entierly arbitrary operation. Do you want to say that
whole ranges of changesets of a repo should better not be pulled
by others then?

Sounds like you would need some heavy use of tags then. Or somehow
mark your testsuite breaking changesets so they can be skipped
by bisect (such a feature is not available yet).

> There is work going on with the group-ing extension which
> formalizes this since some find it is useful to have the extra meta- 
> data made explicit.