Ensuring a merge between branches happens in one d

问题:

This morning I discovered that my co-worker had merged the wrong way between two branches in mercurial --we have a ver5 and ver6 branch, with extra files in ver6. Is there any way (a serverside hook probably) to enforce that the children of any ver5 node be from ver5?

回答1:

Rather than post twice, would my answer to "Mercurial: allow merge from a release branch to the default one, but not vice versa" help? https://stackoverflow.com/a/19926324/1025457

回答2:

Whether you have ver5 merged into ver6 or ver6 merged into ver5 you're still ending up with a child of ver5 that has stuff from ver6 in it.

If, however, you want to avoid a changeset whose branch name is ver5 having ancestors that are ver6 you could do that pretty easily with a hook. Just where you put that hook is the tricky part. If you make it a pretxnchangegroup hook you can prevent people from pushing an offending merge into the server-side repo, but they will have already committed it, and maybe some more changes on top of it, and they'll have a hard time figuring out what to do to fix it. If you can control their local setups you can put in a pretxncommit hook that prevents them from committing the merge, but you can't make them run that hook using only Mercurial tools.

The actual hook, whichever type you make it, could use either of these strategies:

• check if the branchname is ver5 and if so make sure no specific file/content from ver6 is presnet

or

• check if branchname is ver6 and if so make sure neither p1 nor p2 has branchname ver5

TL;DR: It's probably more trouble than it's worth -- stick to shaming.

回答3:

This should do it. It uses a revset query to find any merges into ver5 from ver6.

hg log -r 'children(p2(::ver5 and ::ver6 and merge()) and branch(ver6)) and branch(ver5)'

• ::ver5 and ::ver6 and merge() finds all merges that are ancestors of both ver5 and ver6 branches
• p2(...) and branch(ver6) grabs the second parent (incoming changeset) that are on the ver6 branch.
• children(...) and branch(ver5) then grabs the actual merge changeset that is on the ver5 branch.

I recently needed to figure this out myself, but also needed to ensure that default wasn't indirectly merged into my release branch, i.e. default -> feature -> release.