Frank Birbacher <bloodymir.crap@gmx.net> writes:
Hi!
Am 29.03.12 22:18, schrieb Martin Geisler:
Blocking changes is harder because we always use three-way merges instead of re-playing patches. If you know that you don't need a particular changeset again, then you can back it out. This is just a way of applying the reverse patch from that changeset.
+x +y -x a --- b --- c --- d --- f
Ok, this means removing the changes from a branch. But what for the following: consider a stable and a development branch, just as in your example. Bugfixes go to stable and features go to development. Once in a week someone merges the stable branch into dev to bring all bugfixes into dev. Now someone fixes a bug on stable which shall be fixed differently on dev, here shown as z and z':
dev: ... a --- b --- c --- d --- z' / / stable: ... --- x --------- y --- z
The z and z' are logically the same fix, but syntactically they are different. With svn you could block z from being merged into dev (effective when the merge will happen sometime in the future.) With a three-way merge this seems not easily possible. A merge from will reproduce the z in dev (ancestor is y currently.) So you will have to produce a new common ancestor of dev and stable right on the spot, meaning to do a merge and somehow remove z from it.
You might ask why can z and z' be different in the first place. Well, it may be the coding on dev has changed due to new library functions, new compiler capabilities, or new design of something.
Yeah, this situation is not uncommon with long-lived branches where a bugfix in version 1.x looks quite different when you forward-port it to the 2.x and 3.x series. 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: hg update dev hg merge stable hg revert --all --rev dev # now do the bugfix by hand hg commit -m "merge with stable, hand-ported bugfix #123" 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. -- Martin Geisler Mercurial links: http://mercurial.ch/