Strategies for push/merge problem?

Adrian Buehlmann adrian at cadifra.com
Tue Jul 15 10:12:09 CDT 2008


On 15.07.2008 16:30, Douglas Philips wrote:
> On or about 2008 Jul 15, at 9:47 AM, Adrian Buehlmann indited:
>> On 15.07.2008 14:50, Douglas Philips wrote:
>>> 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.
> 
> Sure it does. I practice test first design, so I commit tests that  
> break because the code isn't there yet.

Well, there's no need to commit that. But obviously we have different
mindsets. You seem to argue that "test first design" implies committing
testsuite breaking changes. It doesn't.

I wouldn't pull such a patch of yours into any repo I would be
responsible for.

Why would anyone else need your breaking test *enabled* in the
testsuite without the code?

> And then if I don't like the
> API, I can try again, and when I like the testing API, I can strip the  
> other experiments before I push, but I certainly do commit the API  
> before I decide to bother implementing it.
> I don't push that out to anyone else until I have the concomitant  
> implementation.
> 
> Of course if I wanted to look like a super-programmer I'd use  MQ to  
> squash it all down into one diamond-polished-all-in-one-athena-from- 
> the-forehead-of-zeus changeset that made it look like I had it all  
> figured out in advance (in that case I wouldn't need a version control  
> system in the first place, but I exaggerate for effect). :)

I'm not a super programmer and I didn't say you have to squash it into
a *single* changeset either.

>>> 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?
> 
> You are simply stating that the policy for your repos is that you can  
> pull to any changeset and have certain behaviors. I'm saying that my  
> policy is different.

Yes. And I said your policy is causing needless troubles
when using bisect.

As soon as you start using bisect, you will notice that.

>> 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).
> 
> mu. I don't know enough about how bisect copes with short-lived  
> branches and merge changesets to comment.


More information about the Mercurial mailing list