A popular method of communicating to fellow team members that you committed data to a subversion repository is to send an automatic email out to all users of that repository. I developed a simple two-script method that is extensible and easy to implement.
First, somewhere relevant to your repositories make a “scripts” folder. This is generally where I store all my svn-pre/post scripts. I put mine in /srv/svn/scripts (my other repositories are in /srv/svn). In this new folder create a new file called svn_email_commit.sh with the following contents.
Then navigate to your repository root and go into the hooks folder. In there, create a file called post-commit with the following contents…
And that's it! Don't forget to chmod +x both of the files above though. Now every time someone commits if they are in the SENDTO field of the post-commit script, they'll get emailed!
The reason I do this in two scripts instead of one is so for each of my repositories I can specify different emails. This helps in a server environment with many repositories with different projects and varying team members, clients or contractors working on the project.
NOTE: You need to put this post-commit file into the hooks folder of each repository that you want emails from.
If you have any problems, please don't hesitate to leave some comments and I'll make edits where necessary. This above works perfectly (with the right software installed) on Ubuntu, Gentoo, and CentOS.
Recently , a server monitoring utility released . One of the newest (and coolest) features is an ! This means that finally, the world can begin to write software the digests the Zabbix API to pull data into various other portals, services, and platforms.
My first foray into this arena led me to making a class to make it easy for myself (and anyone else) to have a simple way to access Zabbix from PHP. First before you use the code you need to make a Zabbix user and group with the proper privileges. From my example below, I used the user apiuser, and password ap1. I recommend making it a LOT more secure.
So here is an example of what your user and his privileges should look like…
And here is what your group should look like when you’re done…
And finally, here’s an example of how to use the API… and as you’ll see in the example below, the hostname of my zabbix server is “genbook”, one of my private development environments. Scroll to the bottom to get the download link for the API and example code.
Grab my Zabbix API Class (v1.0), and example code here:
Your feedback, input, and patches are welcome. For now please use my comment form below to submit feedback. I will setup another method to contact me regarding suggesting improvements in the future.
Long time no see. It's 11pm here now and I'm still in the office. Just though about why not to post to the blog right before I drive home. Really, why not?
I'm mostly working on new vzctl release lately (you can see the progress in vzctl's git web interface ). The ultimate task is to fix most of bugs opened for vzctl in OpenVZ bugzilla (some are dated back to 2007 — no, they are not critical or even major, but anyway). So far are down to one singe page (i.e. scroll bar has disappeared from the browser window) which is a big improvement.
Way A is not that bad, actually, it's definitely better than B, because the result of B is a spaghetti of a functional (e.g. a new feature or a bugfix) and non-functional (e.g. whitespace cleanup) changes. Mixing apples and oranges is a bad thing to do: it makes patch review harder, it makes porting between branches harder, and in case you'll want to revert the patch (say because of a bug in new code) you will also revert those cleanups (which are not buggy). So, if you are not a perfectionist, better follow way A but please not B.
Unfortunately I just can't ignore the bad things I see, so I follow the way C. Sometimes this is very annoying, because instead of implementing a new feature you keep refactoring your code for hours, sometimes even days. No, it's not only whitespace cleanups or fixing typos in comments. Sometimes you see that there are a few identical snippets of code and you put that code into a new function. Sometimes you notice that some function arguments are unused (or always the same) and you remove those. Sometimes you just read the code and see there is a bug in it, and you fix it. Oh, the text of error message is not clear enough — you fix it. The typesetting of a man page is wrong (e.g. bold is used instead of italic for variable argument) — you fix it. You see that a function is not used outside of the source file — you make it static and remove its prototype from a header file. You notice a typo in the function name (and of course also in every place that calls it, since otherwise that code won't compile) — you fix it. A typo in a comment — fix it! And so on, and so forth...
Every single thing from the above paragraph (and some more) happened to me when I was working on the boot order priority feature (the subject of ). So I ended up with 22 (twenty two) code commits, from which 3 implement the actual feature, 1 documents it, and the other 18 are all code refactoring, preparation and minor bugfixing.
The way to perfection is never easy. That doesn't mean we shouldn't try.
Don't forget to chmod +x both of the files above though. Now every time someone commits if they are in the SENDTO field of the post-commit script, they'll get emailed!