Strategies for push/merge problem?

John D. Mitchell jdmitchell at gmail.com
Wed Jul 16 09:00:25 CDT 2008


On Wednesday 2008.07.16, at 05:02 , Sean Russell wrote:
> On Wednesday 16 July 2008 04:16:25 am Adrian Buehlmann wrote:
[...]
>
>> Ha! On second thought it's even simpler than that.
>>
>> If you create a test that is expected to fail, then the test is a  
>> negative
>> one, which means that test is actually only successful iff and only  
>> if it
>> fails. So the test *is* successful if it fails.
>
> If you needed to, you could do this.  But it doesn't follow the test- 
> first
> philosophy that tests are *supposed* to fail.  The whole point is to  
> see a
> bunch of failures and *know* that they fail, and then work, work,  
> work until
> they pass.  What you're suggesting is ginning them up so that they  
> pass, and
> then you work, work, work until they fail.  This has psychological
> disadvantages.

To be clear...

There are test frameworks/tools that support pass, fail, and e.g.,  
"known broken" modes and that's perfectly acceptable in a TDD approach.

Manually inverting a test so that it falls in the pass category and  
having to somehow remember it needs to be fixed is, of course, silly.


At any rate, I commit a number of small changes to my local clone as I  
develop each feature and then, once I have a particular feature  
working/tested/etc. then I collapse it into a single changeset and  
commit that to the "master"/shared repo.


In terms of this new "religious" argument about the push vs. pull  
models, I concur with the folks who've mentioned that a DSCM system  
just exposes problems in people's understanding of how this stuff  
really works.  As in Lake Woebegone, everybody thinks their situation  
is the exception to the rule.  I'm totally sympathetic to the hopes of  
getting groups/organizations to change to using a DSCM system instead  
of the old crap they have been using -- heck, I've been fighting that  
fight for the last few years myself in some projects -- but there  
really a point at which the group/organization has to make a real step  
forward and all of the attempts to "trick" them into using a new tool  
without learning and changing just make the problem worse.

Take care,
John



More information about the Mercurial mailing list