Strategies for push/merge problem?

[Douglas Philips]

On or about 2008 Jul 15, at 11:12 AM, Adrian Buehlmann indited:
>>> "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 am showing one reason why I want to commit, because I want to  
capture a point in time that I might want to return to. Of course in  
your world you have go outside of the version control system because  
you cannot commit at points that are otherwise convenient because you  
seem to be saying that commits are only allowed when the world is in a  
stable place. To me that is one of the reasons I want to flee from  
CVS, because it is rooted in the idea that commit == push. Instead I  
can now push only when it doesn't break the build and my commits are  
all there for anyone to see/understand the progression of the code  
instead of being one huge fait-accompli.

Thing is, I don't care what your policy is so long as I am free to  
choose my own. CVS, for example, forces the same kind of policy you  
describe. Hg allows me more flexibility.


> ... I didn't say you have to squash it into
> a *single* changeset either.

Sure you are. If I change some API in one commit you are saying I have  
to implement it in that same commit; because if I do it in two (or  
more) commits, someone might pull "from the middle" and get something  
broken.
Your policy is that anyone can pull/update to any changeset and have  
the testsuite pass. So you can't have it both ways, you can't have  
your policy and not force me to do one commit.


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

I don't get it, can you explain how bisect is relevant when all  
changesets always pass the testsuite?
How could I even need it if there is no point in recorded changeset- 
commit-time at which the tests don't run?

--Doug