wizkrot.blogg.se - Mercurial windows hook example

#Mercurial windows hook example install#
#Mercurial windows hook example update#

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.

#Mercurial windows hook example update#

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 example 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. This just requires setting up a new hook on the changegroup event.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. Then the central server can send the content to all of the other servers.Īutomatically synchronizing files to other servers can be setup with Mercurial. This can easily be done when using version control to send the content to a central server.

Having the content live on some servers and not on others can be an issue as different users will have a different experience.Īnother solution instead of using Rsync is to automatically synchronize the file or files to the other servers as soon as it has changed. It means that the content may be out of sync by roughly 5-10 minutes. This can be a bit time consuming and also requires more CPU. It has to recursively scan all the directories and search for files that have changed before sending them to another server. Often Rsync is used for this purpose and setup to run every X minutes via cron.

Of course, running multiple servers does add some complexity as the website data needs to be synchronized on all the servers. Easier maintenance - Upgrades can be implemented one machine at a time, with zero impact to the end users.Better reliability - if one machine is down, the others can still serve user requests.

Throughput - It will be able to handle more traffic, since the load is distributed across several machines.

Replicating a website across several locations has several benefits: Here at SoftwareProjects, as part of our multi-homed hosting solution, we host servers in multiple data-centers, where multiple servers run the same websites. Why do we need this auto-push-remotely hook? With this post, I'll walk you through how I developed a Mercurial hook that automatically pushes files from one central location, to a remote server. In some cases, you can even control Mercurial's response to those events. The Mercurial version control system offers a powerful mechanism to let you perform automated actions in response to events that occur in a repository.