Title: Page 108 – Alex Kirk --- * ## 󠀁[Spamhaus.org no longer lists Austrian Registry on its Block List](https://alex.kirk.at/2007/06/19/spamhausorg-lists-austrian-registry-on-its-block-list/)󠁿 * June 19, 2007 * It has come to my attention today that the [almost famous](http://arstechnica.com/news.ars/post/20060915-7757.html) Spam Block List provider put the IP addresses of the Austrian Registry [nic.at](http://nic.at/) on their [block list](http://www.spamhaus.org/sbl/sbl.lasso?query=SBL55625). * The list that Spamhaus provides is actually something good: it allows mail server administrators to automatically block mails arriving from servers that are known to be operated by phishers. * At this point Spamhaus took the wrong term, though. They demanded from the Austrian Registry to delete 15 domains that they consider to be used by phishers, apparently without providing (enough) evidence to nic.at. So nic.at responded that — because of Austrian law — they cannot just delete domains without proof of bogus WHOIS addresses. * I cannot judge who is ultimately right in this dispute (like did Spamhaus provide enough evidence or not), but I can definitely judge that Spamhaus took the wrong decision when they started to block the [IP addresses of nic.at in their list](http://www.spamhaus.org/sbl/sbl.lasso?query=SBL55625). * Welcome to the Kindergarten, guys. * nic.at is bound to Austrian law, and as a foreign company you can’t just come along and ask them to remove certain domains. What if someone would go to your registry and request deletion of spamhaus.org without providing any legitimate reason. * Dear Spamhaus, you need to stick to your policy. Your block list is about phishers, and nic.at did not send out any phishing mails. You can’t just put someone on there because you want to pressure them. * As a result, mail server administrators should no longer rely on block lists of such a provider who misuses his own list for trying to put other companies/ organizations under pressure. So this is the right moment to remove sbl-xbl.spamhaus. org from your server configuration. * Coverage on the German [Heise.de](http://www.heise.de/newsticker/meldung/91417). * **Update 2007-06-20**: They have stopped listing nic.at. Finally they see reason.( They have changed the IP address block to 193.170.120.0/32 which matches no addresses); also see german [futurezone](http://futurezone.orf.at/it/stories/201402/). * nic.at, spamhaus, sbl * [Misc](https://alex.kirk.at/category/misc/), [Web](https://alex.kirk.at/category/web/) * ## 󠀁[Subversion: The Magic of Merging](https://alex.kirk.at/2006/10/12/subversion-the-magic-of-merging-2/)󠁿 * October 12, 2006 * When programming professionally, [Subversion](http://subversion.tigris.org/) is a must-have. Same for system administration: it’s quite a good idea to keep your configuration files (e.g in Linux the whole /etc/ directory) as a Subversion checkout. * So the goal of Subversion (or any other [Source Control system](http://en.wikipedia.org/wiki/Source_control)) is to allow you to do something Apple will introduce with it’s new Leopard operating system: [Time Machine](http://www.apple.com/macosx/leopard/timemachine.html). Go back in time (and restore a version of a file as it was on day x). * Using Subversion on a daily basis is quite easy. Just check in (svn ci) your changes after you have completed a certain task. When you work collaboratively, and someone else has committed some changes, you do a svn up and the changes of the others are applied to your codebase. * That’s all you basically need. But how can you go back in time now? * So you poke around a bit and find that svn up has a parameter -r which let’s you put your checkout to the state in which it was at a certain revision. * Let’s suppose we know that something was ok on monday and is not today. So let’s use the command from above to see what it looks like. ` ~/project/trunk$ svn up -r {2006-10-09} app.php U app.php Voila, there it is. Now we choose to use that code now and throw away all changes that have been committed since. We modify the file a bit and do a check in: ~/project/trunk$ svn ci -m "revert to monday" app.php Sending app.php svn: Commit failed (details follow): svn: Your file or directory 'app.php' is probably out-of-date svn: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). Uh.. ok. So you probably you know that error message already. It is also returned when you want to check something in on a file that has been changed by someone else since your last svn up. * When you check something into a subversion repository, one of the basic rules is that the file you want to commit is “up to date”, i.e. the revision number of your local file (updated by svn up) equals the number in the repository (on the server). * Ok, so, let’s update our checkout so we can re-run the check in. ` ~/project/ trunk$ svn up G app.php So you discover the changes that happened since have been re-inserted to that file again. Maybe Subversion has alerted you of a conflict, because you changed some lines that have been modified since monday also. * Great! Basically we are back to where we started. * Let’s not resign here, but rather use the appropriate command: svn merge. That command is mostly known for merging changes from one branch of development to another. But it can also help you to go back in time. * The parameters of svn merge are to specify a revision range, which changes to be merged, and a source — what part of the subversion repository should be searched for the changes. * Usually one would find this command used in a way like: ` ~/project/trunk$ svn merge -r 15:26 ../branches/first_release/ G app.php So with two revisions specified you define a range of changes which should be merged into the current checkout. Ok so how would us help this here? * You can also specify revisions _backwards_, to go back in time. So to undo the command form before you can write: ` ~/project/trunk$ svn merge -r 26:15 ../ branches/first_release/ G app.php * To put it simple, Subversion generates a diff file behind the scenes that incorporates the changes between the given revisions. Then the changes are merged with the files in the same way the patch command (Linux, Unix, OS X, …) does it. When going back in time, the parameter -R is used which applies the patch in the reverse direction. Voila. * So as a final solution this leaves us with: ` ~/project/trunk$ svn merge -r head:{2006-10-09} . U app.php ~/project/trunk$ svn ci -m "revert to monday" app. php Sending app.php Transmitting file data . Committed revision 27. * For further questions, the [Subversion FAQ](http://subversion.tigris.org/faq.html) is a good starting point when you know exactly what you want (i.e. the correct terminology). (For example _reverting_ does not mean to go back to a previous version of the file, but rather to remove the changes you did locally). * There is the [subversion book](http://svnbook.red-bean.com/) (also published by [O’Reilly](http://www.oreilly.com/catalog/0596004486/)), of which the [Guided Tour](http://svnbook.red-bean.com/nightly/en/svn.tour.html) is a good starting point. * The process I described above as a trial and error is also described in that book at [Undoing changes](http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo). * Also [OSCON: Subversion Best Practices](http://bradchoate.com/weblog/2006/07/27/oscon-subversion-best-practices), a transcript of a talk given by the subversion creators (Ben Collins-Sussman and Brian W. Fitzpatrick) by Brad Choate has some good tips. * Have fun :) * subversion, merge, revert, time machine * [Code](https://alex.kirk.at/category/code/) [Previous Page](https://alex.kirk.at/page/107/?output_format=md&term_id=1122) [Next Page](https://alex.kirk.at/page/109/?output_format=md&term_id=1122)