Frage zu SVN und zur MySQL Sicherung

huhu ihr lieben,
ich habe grade mal mit einem bekannten über svn geredet. ich hab mir jetzt ein repo besorgt. jetzt stellt sich nur die frage, wie soll ich die ordner strucktur anlegen. mein bekannter meinte, ich solle einen projekt ordner erstellen, darein pack ich dann einen trunk, tag und branch ordner. in den trunk kommt mein bisher fertiges projekt rein, sowas ist es klar, aber wofür sind tag und branch dann gut? das wusste er selber nicht mehr genau... ich meine mal gelesen zu haben das in tag die fertigen releases kommen und in branch eine kopie des trunks, an dem man gerade arbeitet. ist das richtig oder nicht?
desweiteren mache ich mir momentan gedanken, wie ich am besten meine mysql datenbank sichern soll. da ich oft am meinen laptop abeite hab ich mir halt das svn besorgt, für die files, aber wie mache ich das mit der datenbank dann? ich hab nämlich kein nerv jedesma mich ins phpmyadmin einzu loggen und einbackup zu machen oder eins reinzu spielen. habt ihr da vllt eine gute idee??

Bei Wikipeida ist das Konzept der Tags und Branches kurz erläutert: Subversion
Bzgl der Mysql-Backups: Ich nehme mal an du bist unter Windows. Dann erstellst du dir eine kleine .cmd-Datei, die ein Backup erstellt. In die CMD-Datei schreibst du dann den Befehl zum exportieren. Google hat mir eben diesen Forenbeitrag geliefert, sieht eigentlich ganz ok aus.

Ich nehme ebenfalls mal an, du hast php & mysql - da könntest du auch den mysqldumper benutzen - den müsstest du aber auch extra im browser aufrufen, unter linux lässt sich der toll automatisiert benutzen..
Zum Exportieren ein Nachtrag:
db_sichern.bat:
FOR /F "tokens=1,2,3,4,5 delims=/. " %%a in ('date/T') do set CDATE=%%b%%c%%d
mysqldump -u -p database_name > /path/to/db_%cdate%.sql

Hallo, das mit der bat datei ist mir auch schon durch den kopf gegangen... nur soll ich die sql backups dann in mein projekt ordner packen und auch auf den svn hochladen?
achja und den svn artikel habe ich mir auch schon angeguckt.. leider verstehe ich immer noch nicht so wirklich wozu man branches benutzt.

Du must immer davon ausgehen, dass solche Tools wie Subversion auch in größeren Projekten verwendet werden. Da hast Du dann in trunk den allerneusten Projektefortschritt, an dem Ende endsteht die allerneuste Version. Z.b. die Version 2.2. In Branch stecken die allerneusten Projektfortschritte von älteren Versionen, die schon zum Kunden ausgeliefert wurden, und dem entsprechend gewartet werden müssen. Also z.B. 2.0, 1.8, 1.6 usw.. Zusätzlich sind dort Zwischen-Versionen, die ein Kollege erstellt, weil er größere Umbauarbeiten (z.B. am Trunk) machen muss, dabei aber seine Kollegen nicht stören möchte. Wenn er mit seinen Arbeiten fertig ist, merged er seine Änderungen in den Trunk und könnte den Umbau-Branch dann löschen. In Tags sind dann die Stände, die aus bestimmten Gründen einen Namen brauchen. Z.b. bei jeder Software-Auslieferung an den Kunden, wird vom Trunk oder von einem Branch eine Kopie mit entsprechendem Namen (z.B. wenn an der Version 1.8 eine neue Fehlerbehebung gemacht wurde, wird /branch/1.8 nach /tag/1.8.15 kopiert) erstellt.
Wie genau man das nutzt hängt davon ab, wie die Anforderungen des eigenen Projekts sind. Bei Financial-Rumors arbeite ich alleine am Projekt und benutze nur ganz selten Branches und kopiere vor einer Installation den trunk nach tag. Nur, wenn ich größere Umbauten mache, sichere ich den aktuelle Stand in einem branch, um vor dort aus ggf. Fehlerbehebungen machen zu können. Direkt in der Hilfe von Subversion stand meiner Meinung nach ein paar ganz hilfreiche Sätze zu dem Konzept.

für die sicherung kann man auch einfach mysqlhotcopy nehmen, das die binären db-dateien nach einem lock im laufendem Betrieb kopiert. Dürfte die schnellste Möglichkeit sein.

Damit könnte es aber zu Problemen kommen, wenn

• sich bei einem Update von MySQL was an der Binärstruktur ändert und er die daten smoit nicht mehr richtig lesen kann
• wenn gerade ein Update der Datei erfolgt. Ich weiß nicht, in wie weit MySQL die Dateien lockt.

spätestens nach nem repair table ist das updateproblem gegessen.
mysqlhotcopy lockt die Tabellen vorher, sagt also mysql vorher bescheid.

Das Mysqlbackup würde ich per Cron automatisieren, allerdings natürlich auf eine spte/frühe Zeit, bsp. in die frühen Morgenstunden. Denn bei größeren Datenbanken kann das leicht bis mittel die Performance der Anwendung in den Keller ziehen.. und für ein richtiges Backup sollte man sich die erstellten Dumps (ein gz drüber jagen kann bei Sqldumps nie schaden.. ) auch auf einen anderen Ort ziehen. Sprich: Entweder manuell runterladen oder ebenfalls automatisiert auf einen anderen Server/Ort kopieren. Vor allem bei Datenbanken besser SSH/SCP statt FTP nutzen..
Die andere Möglichkeit wäre natürlich Replikation, aber dafür muss das Projekt schon groß genug sein, damit sich das (Installation und Wartung) lohnt (Replikation = mehrere Server mit gleichem Stand, mal vorsichtig mit LBs verglichen).
Die Repos würde ich einfach komplett kopieren (mitsamt Log & Co), dann ist alles später wieder da. Ich weiß es nicht (da noch nie gemacht), aber dafür hat bestimmt auch schon jemand nen nettes Scriptchen gebastelt.
Bezgl der Versionsverwaltung: Die Handhabung kann ich auch nur bestätigen, allerdings arbeitet bei uns auch kaum jemand mit tags.. die Release Versionen erhalten eigene Branches (bsp. zum Bugfixen, zum "Festhalten" eines Standes), der laufende Prozess landet im trunk (jeweils mit Projektname).