Restrict the content of push's to avoid accide

Question

(This is a follow-up question to my earlier question about how to manage standard development and customer-specific development in a cvs.)

We are using different branches in mercurial to distinguish between standard development (development of our standard software) and customer-specific development (development of customer-specific modifications of our standard software).

So, lets say we have the following branches:

• default (standard development branch)
• revision1.0 (standard development branch for bugfixing)
• revision1.1 (standard development branch for bugfixing)
• customerA (a clone from "revision1.0" with some changes)

When Customer A wants to upgrade from 1.0 to 1.1, we simply pull from revision1.1 to customerA (and solve the merge conflicts). So far, so good.

What I want to avoid is that a developer accidently merges some customer-specific code into a standard development branch. We can identify "customer-specific code" by its Java namespace.

Is there any way to do this?

EDIT: changed "push" into "merge" as this is the correct term

Answer 1

You may prevent accidental pushes by not allowing pushes at all. Assuming, there is some wise administrator of main (possibly "team") repository, you may rely on using exclusively pull requests. This prevents any pushes, and only administrator of main repo has right to pull stuff into main repo. Or - in case things do not seem in acceptable shape - reject it.

Pieter Hintjens is proposing use of dedicated repositories (one repo per purpose, so one repo may play a role of a branch). And one of his reasons for this organization is just to prevent accidental mess created by push into a repo. See "Robustness in Conflict" and "Guarantees of Isolation" in http://hintjens.com/blog:24.

Note, that this seems to fit a bit better for use of git then Mercurial, as Mercurial keeps branch names burned into commits, so you are not so free to play with them.

Answer 2

You can block developers pushing bad commits or merges to your "central" repository but you can't stop them from doing them locally. So you could use, for example, a pretxnchangegroup hook to make sure a push doesn't result in customer specific code in the revision1.0 branch (or clone), but that will just reject the developer's push. He or she will still have the bad commit locally and will need to unravel it.

There's some confusion in the comments above because you're conflating terms. One merges things between (named) branches and pushes things between repositories.

Answer 3

This isn't really an answer to the question, but if you are using branching instead of clones, then, in my humble opinion, the issue isn't worth worrying over.

As long as developers merge branches using branch names rather than revision numbers, and the branch naming for customer branches is fairly distinct from other branches, it would be quite difficult for someone to accidentally do 'hg merge customerA'. We (team of 12 devs) have had a similar branching strategy running for a couple of years and have yet to have someone accidentally merge the wrong branches.

In the rare case it does happen, it will usually be solvable in an hour or 2 with reverse commits. And since it seems you don't merge customerA back to anything, you can even do a reverse-reverse commit on that branch to bring the changes back.