As described in: http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html I thought I could write a small hook which rejects checkins with malformed commit messages. Thats no problem, the issue I encounter is the following work flow:
If a developer makes let's say 10 local commits, some of them are malformed, and then pushes them to the central repository all will be rejected, but he is unable to edit the old commit messages since rollback will work only once..
How do you solve this?
Using the HistEdit extension, you can change the commit message locally, then push back the whole changes in the main repository.
I suppose you can't mandate developers to use the same precommit hook to check commit messages, because it's not a centrally-managed project?
An alternative to #gizmo's answer is to let developers use MQ and mandate code review before pushing (or better, someone pulling from them). Then if reviewers (or some review scripts) spot the malformed messages, the developer can use qrefresh to change the message.
You need to be careful about a couple of things in that workflow, though:
NEVER EVER push/pull unfinished patch, even though qfinish does not change the hash. It's just too easy to screw up.
Make sure developer qcommit every time before sending things out for review, otherwise you won't know if s/he slips in other changes in the next iteration (not that s/he would, but s/he could).
Related
I have a utility script that will configure the local developer instance to mimic a specific production one - copy over the correct connection strings, client files, etc - thereby making it easy to investigate certain issues.
Because this is all done locally this changes files in the working directory. The first thing the script does therefore is print out a big fat warning to caution developers not to commit and revert changes when they are done. However it is possible to forget or miss this warning as cruft from my build system scrolls by and I wonder if its possible to go further.
Is it possible to do something to the hg repo so that a commit will be rejected and the developer would have to revert first?
I realize there are some variables to the question as far as revert what and commit what but given that I'm not even sure that this is possible, I am willing to take close-with-caveats for an answer.
This is exactly what hooks are for. You would need a precommit hook on every repo or possibly the pretxnchangegroup.
By creating a precommit hook (script) that checks for a specific file or a specific change, you can fail the commit and print out whatever warning you need. The return value of the script indicates to mercurial if the transaction is valid or not.
Use the following generic sample to check for the presence of certain files that would be committed, before accepting or rejecting the changesets.
I need to collaborate on a Mercurial repository (let's call it "foo") with some people who are novices at version control in general, Mercurial in particular.
I am trying to come up with a workflow that will enable us to use Mercurial without a lot of extra effort on either their end (confusion) or my end (cleanup).
My concern is that as novices I need to expect them to make errors, and I need to allow them to do so in a controlled way, otherwise they won't use the tool at all because they're too scared. But I don't want a bad change to pollute the repository unnecessarily.
I do not expect them to be able to merge properly or to use the mq extension. This is not
a matter of underestimating them, instead it is a realistic assessment given past experience with SVN and my own experience with Hg.
Which of the following approaches would make the most sense? Or if there's a better approach, what is it?
We have a repository foo-submit, read/writable by all, and a repository foo-trunk, readable by all but writable by admins. Users pull from foo-trunk, and push changes to foo-submit. Cleanup: If I find a good change, I let it through as is; if I find a bad change, I "bypass" it by merging with the previous version.
We have a repository foo-trunk readable by all, writable by admins. Each user is responsible for maintaining their own clone which is read-accessible to the rest of the team. When someone wants to push a change, they let me know and I pull it from their repository, with proper cleanup as necessary (same as in #1)
We have a repository foo-dev, read/writable by all, and a repository foo-trunk, readable by all but writable by admins. Users pull/push to foo-dev, and work in named branches if they need to do extensive development. I am responsible for performing merges and cleanup. The foo-trunk repository is merely for having a "clean" copy that has branches where the tip is always in a good state.
Good question, and one that I've never seen a great answer to.
That said, I like option 2. This is the "Pull Request" model used by the Linux Kernel and made popular by GitHub. It allows the admins to act as gatekeepers / reviewers, only allowing good change-sets to get past them when they're happy. If they decide a developer hasn't delivered something worthy, then the pull request is rejected (with reasons). Then the developer can go away, fix up their code / repo, and submit another pull request.
Running a server with something like RhodeCode on it can help keep on top of pull requests. As things grow you can have lower level gatekeepers that deal with subsystems, and higher level gatekeepers that deal with the whole project.
The bit I've never quite got my head around is what should happen to change-sets that are rejected, and that the developer decides to abandon rather than fix up and try again. They could be closed, but then could possibly appear by mistake as part of a future pull request. They'd be harmless, but possibly confusing. The alternative is stripping them, but that sounds like giving people tools they'll cut themselves on.
The other 2 options you give deserve a little comment.
1 is similar to 2. You're still doing a "Pull Request" type flow, but now you have server side branches which mirror the developer's clones. There's little difference and this is how a RhodeCode, GitHub, BitBucket server would let you work, except you don't have to go searching for changes. The server would tell you they're waiting for you to look at.
3 has the problem that everyone's changes are all merged together on foo-dev before you get to them. They would start becoming inter-dependent, and cherry-picking is going to be messy. You'd probably end up grafting change-sets on to foo-trunk which means you're creating new change-sets with new hashes. When the developers pull those they'll now have the change in two places; their original foo-dev version and your grafted foo-trunk version. This doesn't sound sustainable to me.
Best way i can think of if you don't want to use mq (understand with the least hassle for you) is to have your dev
create their own branch for the current feature being developped
merge it back to the main dev branch (or graft/transplant) when it's completed and validated
and then close the branch.
In the long term see for them to learn mq, it's not too hard to grasp.
3a - foo-dev has protected default branch (only some admins can push/merge-to this branch), users use named branches
we're moving from Subversion to Mercurial now. In Subversion there was possibility to add custom column into log (e.g. bug id) and force user to fill this column on every commit.
Is it possible to implement such feature in Mercurial?
Yes it's possible.
But before you go and do that, why isn't it enough to require bug fix commit messages to uphold to a certain pattern?
i.e. util: rename the util.localpath that uses url to urllocalpath (issue2875) (taken from Mercurial's repo)
Then you can install a hook on your central repository that scans incoming commit messages, and does whatever is needed when that pattern is found.
Furthermore, why would you want to force this on every commit? Is this for a QA team that should only commit bug fixes? If that's the case, a pre-commit hook that greps the commit message for the pattern sounds appropriate.
If you still want the extra field: when Mercurial commits something, it is possible to pass it a dictionary of strings, which you can fill with anything. See the transplant extension on how you might do that. You would also need to wrap the commit command and add a new command line option to it.
But I strongly suggest you think twice before doing this, because aside from the time consuming work involved in coding, testing (and maintaining this between Mercurial releases), you would also need to ensure that it is deployed on every environment where Mercurial is used.
I'd like to write a script that examines the incoming changesets on a push to a mercurial server and rejects the push if the changesets do not conform to a particular standard. It seems like my options are the prechangegroup, pre-changegroup, and pretxnchangegroup hooks. Unfortunately, the prechangegroup and pre-changegroup hooks do not appear to have access to the incoming changesets, so I would need pretxnchangegroup. But according to the documentation at http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup, this can lead to inconsistent state for people using the repository while the hook is executing:
"While this hook is running, if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent. This may lead to race conditions if you do not take steps to avoid them."
I'm really not crazy about random weirdness happening if someone does a pull while my script is in the process of rejecting a changeset. Is there another hook that I can use? If not, what are the "steps to avoid them" that I need to take? Is there a way I can lock the repository during my hook?
If you expand the comments for the quoted paragraph, Meister Geisler confirmed some users' observation that the issue was resolved since hg 1.2, such that the not-yet-permanent incoming changesets are not visible, thus will not be pulled.
My boss is constantly complaining about the need to commit a merge (-1 head type of situation). Are there any settings in tortoise that tell it to automatically commit after a merge?
I can see reasons why this is not a good idea (events where you merge items inappropriate and wish to undo it) but my boss also countered that you can just rollback or revert in such situation. Thoughts?
You can have a look to the fetch extension.
According to http://tortoisehg.bitbucket.io/manual/2.9/sync.html Tortoise HG supports the fetch extension if it is enabled.
However, you will have to enable the extension in every hgrc file manually, there's no way to enable an extension automatically trough the repository.
Concerning the potential problems, like your boss said, you can always rollback if something went wrong. So if your boss requires this extension, you can please him without fear :)