Strategies for push/merge problem?

Giorgos Keramidas keramida at ceid.upatras.gr
Tue Jul 29 16:15:10 CDT 2008


On Tue, 29 Jul 2008 16:42:09 -0400, Christopher Weimann <christopher at weimann.us> wrote:
>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.

Precisely.  This is why some of the things that are 'common' in CVS are
not even necessary with Hg :)

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

I think it's a feature too.

It does not *enforce* anything that can prevent _all_ problems of
half-done changes, i.e. someone may still do:

    vi include/header.h
    hg ci -m 'Update header.h for foo' include
    hg push

    vi lib/libcore/blah.c
    hg ci -m 'Catch up with header.h'
    [ forget to push here ]

    # At this point the tree may be broken for everybody else.

Hence it is still possible to do stupid things with Mercurial.  It's
just a lot easier to _avoid_ being caught by surprise, when one gets
used to treating changesets in a way that makes them "self-sufficient".



More information about the Mercurial mailing list