Strategies for push/merge problem?

[Christopher Weimann]

Douglas Philips wrote:
> 
> Let me see if I have understand this correctly:
> Developer A changes files f1.c, f2.c, f3.c
> Developer B changes files q1.c, q2.c, q3.c
> 
> because both change independent sets of files, subversion will let  
> them both push, creating a merged repo of A's f1.c, f2.c, f3.c and B's  
> q1.c, q2.c, q3.c and neither will know or be told that what has been  
> created in the central repo never actually existed on any developer's  
> machine?
> 

You are correct.  That matches understanding of CVS and Subversion.  I just tried it to make sure my understanding is correct.  I Developer A can change a header file or a library source file and commit that.  Developer B who hasn't updated yet, changes some application source that uses that header or  library and commits and nobody is the wiser that the repository now holds a code set that may be completely broken.

Mercurial would prevent from pushing because there would be new heads.  This points out to you that something has changed and requires some action on the developers part.

This entire thread boils down to this difference.  

Subversion will blindly accept changes to different files as though those files have no relation to each other.

Mercurial won't.

I think this is a Mercurial feature.