Frank Birbacher <bloodymir.crap@gmx.net> 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/