In verteilten Systemen kommt es des öfteren vor, das unterschiedliche SVN Versionen zum Einsatz kommen.
Wenn euer SVN diese Meldung ausgibt:
svn: This client is too old to work with working copy 'xyz'. You need to get a newer Subversion client, or to downgrade this working copy. See http://subversion.tigris.org/faq.html#working-copy-format-change for details.
kann das Python Script change-svn-wc-format eine SVN WorkingCopy in ein bestimmtes anderes SVN Versionsformat wechseln.
Da GZIP selbst keine ganzen Ordner packen kann, kann man TAR das gepackte Archiv erzeugen lassen.
user@server: tar cvzf ordner.tar.gz ordnername user@server: tar zxvf ordner.tar.gz
Hier findet Ihr den Shell Scripting Guide:
Dann kann man beispielsweise so kleine Helferlein zum Löschen von Logs und Caches wie diesen hier basteln:
#!/bin/bash
cd `dirname $0` # go to scripts dir
cd .. # step ahead
arr[0]='Application1/app/cache/*'
arr[1]='Application1/var/cache/*'
arr[2]='Application2/application/cache/*'
arr[3]='Application2/application/logs/*'
arr[4]='Application2/pub/tmp/*'
arr[5]='Application3/application/cache/*'
arr[6]='Application3/application/logs/*'
arr[7]='Application3/pub/tmp/*'
i=0
while [ $i -lt ${#arr[@]} ]
do
rm -rf ${arr[$i]}
echo "${arr[$i]} deleted"
(( i=$i+1 ))
done
XDebug ist das sehr beliebte und allseits bewährte Tool, das nicht nur Stacktrace und var_dumps ausgeben kann, sondern ebenso für CodeCoverage, echtes Debuggen, Profiling und Testen mit PHPUnit gedacht ist.
XDebug kann Profiler Dateien erzeugen, die man mit KCacheGrind perfekt auswerten kann. So bleibt kein Flaschenhals in der Applikation unbemerkt.
Mit diesem kleine Eintrag werden URLs mit einem Slash am Ende auf die gleiche URL ohne Slash am Ende geleitet. In meiner Rails Anwendung verursachten URLs mit einem Slash am Ende einen 403 – Forbidden.
RewriteEngine On RewriteRule ^(.+)/$ $1 [R=301,L]
Folgender Kommandozeilen Befehl löscht alle .svn Verzeichnisse in einem Ordner.
Im Detail sucht das Kommando find
im aktuellen Ordner (.) rekursiv
nach Verzeichnissen (-type d)
mit dem Namen .svn (-name .svn)
und piped (|) diese Liste
nach xargs,
welches dann an erster Stelle (-0) der Liste
mit der Löschoperation (rm -rf) beginnt.
find . -type d -name .svn -print0 | xargs -0 rm -rf
Um im schlanken Webserver Lighty eine HTTP Authentifizierung für bestimmte Verzeichnisse zu erzeugen, ist es notwendig, in der /etc/lighttpd/lighttpd.conf das Server-Modul mod_access und mod_auth zu aktivieren.
server.modules = (
"mod_access",
"mod_auth",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_cgi",
"mod_fastcgi",
"mod_rewrite",
"mod_magnet",
"mod_redirect",
"mod_status",
)
Um ein Verzeichnis unterhalb eines bestehenden Webroots nun mit einer Authentifizierung zu schützen, tragen wir das in der /etc/lighttpd/vhosts.conf ein.
$HTTP["host"] =~ "(^|\.)domain\.tld$" {
server.document-root = "/home/user/pages/"
auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = "/home/user/passwd.txt"
auth.require = ("/" => (
"method" => "basic",
"realm" => "admin",
"require" => "valid-user"
)
)
}
Zu guter Letzt benötigen wir noch die /home/user/passwd.txt die die betreffenden Authentifizierungsinfos bereit hält.
user:basic_encoded_password
Fortan ist der Ordner /home/user/pages/ passwortgeschützt.
Möchte man einen Unterordner passwortschützen, trägt man diesen statt des Slashes ein:
auth.require = ("/subdir/" => (
"method" => "basic",
"realm" => "admin",
"require" => "valid-user"
)
)
Nachdem ich das offizielle Agavi DOC durchforstet habe und keine Lösung für meine Testumgebung fand, stieß ich auf diesen Link hier:
simonholywell.com/article/installing-agavi-on-xampp-windows
Herr Holywell selbst hat eine prima Einführung in die Installation von Agavi auf XAMPP und Windows geliefert.
Hier der Post im Original:
Having recently heard of the Agavi project from a web framework showdown at a PHP conference in the UK I have decided to trial it. My setup is a WinXP computer with a default install of the latest XAMPP which has thrown up some issues with installing and building Agavi. Please see my hints below to overcome these issues.
1. Open a command prompt (type cmd in the run console)
2. Navigate to your XAMMP PHP directory. Mine is C:\xampp-test\php
3. Execute pear.bat channel-discover pear.agavi.org
4. Execute pear.bat install agavi/agavi
Agavi is now installed! Now we just need a new default project to work from.
Agavi needs to be told where the phing batch file is stored.
1. Edit the agavi.bat file in the XAMPP php directory. Mine is C:\xampp-test\php\agavi.bat
2. Change set PHING_COMMAND=phing to contain the full absolute path to phing.bat which is in the XAMPP php folder. Mine looks like this: set PHING_COMMAND=C:\xampp-test\php\phing.bat
Begin setting up your project directory.
1. Create a new directory in your XAMPP directory. Mine is C:xampp-testhtdocssimonholywell.com
2. Create an empty text file called build.properties in the directory (this banishes a build error where phing fails if it cannot find the file)
3. Open a command prompt and navigate to the new directory
4. Execute agavi.bat project The agavi.bat file is stored in the XAMPP php folder. My command looked like this: C:\xampp-test\php\agavi.bat project
5. Follow the prompts the installer gives you (hitting enter will supply the installer with the [default] value)
Agavi should now be setup for your project. View it in your browser to verify.