Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?

Subject: Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-04-02 04:49:16

Frank Birbacher <bloodymir.crap_at_[hidden]> writes:

Hi again :)

> Am 01.04.12 12:09, schrieb Martin Geisler:
>> With Git or Mercurial you do the merge of z' and z and then resolve
>> the conflicts in favour of z'. There's no direct way to block a
>> changeset from "flowing" into a given branch -- since changesets
>> don't "flow" anywhere when you merge.
>>
>> With a simple scenario like the above it's not a big problem: you
>> merge stable into dev after every one or two changes on stable. So
>> you can do the merge, revert back to dev and then port the bugfix by
>> hand:
>
> This means the person to do the fix has to do a merge, too.

Not necessarily: I can commit a bugfix to stable without being the one
who merges stable in dev.

In practice, I'm probably the one who are in the best position to do the
merge since I understand my bugfix and so I can decide how to apply it
on dev. But I can delay the merge or ask someone else to do it instead.

> This means to educate everyone on the team to do proper merges, right?
> Ok, merging should be part of daily work, especially with hg/git, but
> this is not true for development teams in general.

If you're using branches (with any system) then I think you should
educate the entire team about them.

But you're right that people can use a CVCS for years without knowing
about branches. That's a big change with DVCS: branches are first-class
concepts in the system and people use them every day. This means that
people stop being afraid of merges.

But even with CVSC people are normally not afraid of merges:

  svn update

is *merging* your changes into the latest changes on the server. Even

  svn commit

is doing a merge -- this time it's a server-side merge between files you
touched and files I touched.

With a DVCS those merges are explicit and so people are more aware of
them. But if you could do 'svn update' and 'svn commit' before, then you
can also run 'hg merge' or 'git pull' -- it's the same thing.

Because people learn about branches and merges with a DVCS they suddenly
realize that they can pull of all sorts of "advanced" strategies like
keeping long-term bugfix branches around. They are not really advanced,
since it's just more of the same everyday commands that people are used
to at that point: 'hg update default', hg merge stable'.

>> The advantage of doing a such a "dummy merge" where you throw away
>> all changes from the other branch is that you record the merge in the
>> history. So future three-way merges will not re-merge this change.
>
> Correct. But it is a somewhat more complex workflow compared to a svn
> blocking merge. So a disadvantage of git/hg compared to svn. A rather
> strong one IMHO, but maybe not for boost development.

I don't know enough about how you organize the development to comment on
that. I think you should try it out on a subsystem first and see if this
is a problem.

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/