Strategies for push/merge problem?

Adrian Buehlmann adrian at cadifra.com
Wed Jul 16 02:46:43 CDT 2008


On 15.07.2008 21:58, Benjamin Smedberg wrote:
> Adrian Buehlmann wrote:
> 
>> But I wonder if a project e.g. like Mercurial would accept a changeset
>> like this:
>>
>> "This is what I achieved until 5pm. Currently, the testsuite is
>> broken, but if I manually set variable x to an illegal value z, I
>> can almost do feature X. I will continue tomorrow morning, but I had
>> to commit this state in order to being able to take it home on my
>> USB stick RIGHT NOW (need to run!)".
>>
>> Who wants to see such a changeset in the eternal history of any non-toy,
>> non-hobby, non-single-developer, non-throw-away project?
> 
> Contra-example:
> 
> In Mozilla we are working on some very large automatic refactoring projects. 
> I am currently maintaining these projects as a patch queue, but when it 
> comes time to push them finally, I will be pushing something like this:
> 
> A - manual rewrite of class X, reviewed by Joe
> B - manual rewrite of class Y, reviewed by Amy
> C... about 120 patches
> X - automatically rewrite removing stack nsCOMPtrs
> Y - automatically rewrite class hierarchy
> Z - automatically rewrite NS_IF_ADDREF
> 
> Every one of these changes between A and Z leaves the repository in a broken 
> state: only Z passes unit tests and works correctly. However, it would be 
> extremely dumb to commit them all as one merged commit: this is because 
> other people who have ongoing work will need to reproduce the automatic 
> rewrites.

I don't know what you are doing here. Sounds like this would be far too
complex to dissect in this thread or even on this list here.

> As another example, we often have project branches that are developed on a 
> single platform: they do all the real work and make sure the unit tests all 
> pass on mac, and then go back and fix up linux and windows.

Why don't you simply *disable* the linux and windows tests in these csets
then if you know that these changes break those tests?

That way you still would fulfill the invariant of not breaking the
default daily (hourly or whatever) build (assuming it runs the testsuite
on mac, linux and windows).

All I say is: don't deliberately break the daily build.

> This discussion has wandered rather off-topic though, no?

Probably so, but it emerged from an essential point raised by Paul about
lost invariants over trees which demonstrates how some people use
Mercurial in ways that are at odds with the invariant tree model, which
Mercurial supports so well.

The bisect command is an essential tool if you have a complex
criss-crossing history which may result from using a DVCS in some ways.
If you render bisect unusable to do some searches by dropping the invariants,
you loose an essential part of the power of Mercurial.

But of course, you are free to use Mercurial in whatever ways you
believe are useful for you. Every project has its specific needs
and expectations.




More information about the Mercurial mailing list