Using commit messages is better than using named branches if you plan to have thousands of bug numbers. Make it a custom script that will ask for a bug number, put that into a commit message template and then start and editor to let the developers enter the commit message. Validating the commit message is best done by configuring ui.editor. There wont be any online validation, but they can follow pretty much the same workflow as in Subversion.
You can also ask the developers to put the bug number into the commit message, just like with Subversion. When pushing to the server, it's easy to parse the pushed changesets (in a changegroup hook) and update Bugzilla. The following commits will then contain the "bug-123" label inside them. Have your developers run $ hg branch bug-123īefore starting work on bug number 123.
This can be done with named branches in Mercurial. There wont be anything in the changesets that tie them to a Bugzilla bug - it's only Bugzilla that knows that changesets belong to what bugs.Īnother way would be to embed the bug numbers into the changesets themselves. That is one way of associating changesets with an external issue tracker.
When the developer enters the bug number, the script can look at hg outgoing and associate the outgoing changesets with the bug in Bugzilla. The pick-bug-number.sh script should first check that the developers are pushing to your central repository (and not, say, to some other repository on their laptop) and then ask them for a bug number.
MERCURIAL WINDOWS HOOK ON LOCAL COMMIT ADD COMMENT INSTALL
So you could ask the developers to install a hook like However, hg push is of course a good time to go and update Bugzilla since the developers are online when pushing to the central repository. The push command is only moving changesets around, not changing them. The important thing to remember is that changesets are (nearly) immutable, which means that it's too late to add a bug number when the developers are running hg push.
0 kommentar(er)
