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