Strategies for push/merge problem?

Douglas Philips dgou at mac.com
Tue Jul 15 09:30:35 CDT 2008


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. 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). :)

>> 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.


> 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.

--Doug

P.S. Plus "what Paul Moore said" (in: <79990c6b0807150723u4ee5c8e5ta9f6bfa18f6e687c at mail.gmail.com 
 > which arrived while I was composing this reply)



More information about the Mercurial mailing list