Dean Roehrich <Dean.Roehrich at sun.com> writes: > To revisit a concern of mine from late January... > > My team may switch to mercurial and we'd like our central hg repository to > validate a few things on each changeset. We'd like the server to verify the > format of the commit message (first line is the CR number, space, CR synopsis, > second line is blank,...), and we'd also like to parse the CR number from the > commit message and verify that CR number against the approved CRs for that > repo, and verify that an extra head isn't created,...and more stuff, I'm sure.
> The current list of mercurial hooks does not quite allow the scenario I had > envisioned. I thought we'd have one main repo, "P", from which every team > member would push and pull. The prechangegroup hook on P sounds good at first > glance, but it would have to reach back to the user's repo and rummage round > there--nix that idea. The pretxnchangegroup hook on P appears to be the only > way to achieve the server-side enforcement. The downside of this hook is that > it doesn't fire until the csets have already been applied, and another user > can pull those changes before the enforcement mechanism can decide to > abort&rollback this changegroup. It should be possible to implement our own locking to guard against that, which would be another option (perhaps lighter weight than the one you outline below). -- Rich > An alternative is to use cascading repos; one for pulls, "P", and one for > pushes, "Q". Use pretxnchangegroup on P, and have P execute a changegroup > hook to push to Q. A prechangegroup hook on Q would ensure that only P can > push to it. (This is how teamware is used with on/nv, correct?)
