Team Entwicklungsumgebung

**AmicaNoctis** · 18.03.2011, 13:17

Hallo,

wieso ist Subversion umständlich? Viele Entwicklungsumgebungen haben das gleich mit integriert und der Commit-Befehl (nicht Einchecken) ist ein Knopfdruck. Genauso wie z. B. TortoiseSVN dir das Kontextmenü jeder Datei und jedes Ordners um die entsprechenden SVN-Befehle erweitert.

Wenn du sagst, dass es einfacher sein soll, wie hättest du es denn gerne?

Gruß,

Amica

**Thurial** · 18.03.2011, 13:45

Hallo Amica,

vielleicht hab ich dazumal einfach etwas falsch eingerichtet. Jedoch da wo ich es ausprobiert hatte, musste ich die Dateien editieren, per FTP auf das Testweb schieben und wenn alles in Ordnung ist einchecken.
Dann hat es ja im Subversion eine neue Version generiert mit meinen Änderungen, jedoch war das dann noch nicht im LiveSystem. Dann musste ich ja noch die Daten mit dem LiveSystem abgleichen. Und da wir häufiger kleinere Änderungen haben, kann das dann doch etwas umständlich sein.

Hast du per Zufall gerade eine Anleitung zur Hand, wie man das Subversion "schön" einrichten kann? Dann test ich das direkt mal dieses Wochenende. Wie gesagt, ich hab nichts gegen Subversion, aber evtl. hab ich es einfach etwas falsch "bedient"

Gruss,
Alex

**AmicaNoctis** · 18.03.2011, 14:21

Das SVN Repository sollte direkt auf dem Testsystem sein. Jeder Mitarbeiter checkt sich eine lokale Working Copy aus. Wenn jemand etwas committet ist es direkt da. Falls dabei mal ein Fehler passiert, ist das nicht schlimm, denn du kannst ja jederzeit zu einer früheren Revision zurückgehen. FTP brauchst du dann nicht mehr, den Subversion übernimmt beim Commit das Hochladen und beim Update das Herunterladen der aktuellsten Version.

**Thurial** · 18.03.2011, 14:48

Aber ist das dann nicht so, das es immer wieder eine neue Version gibt?
Zum Beispiel wenn ich nun was an einer PHP Datei mache, irgendwas funktioniert nicht ganz so, und mach so ein kleines Debugging (quick&dirty mit echo)... Dann muss ich es ja speichern, commiten, testen, neuspeichern, commiten etc. Oder versteh ich da etwas falsch?

**AmicaNoctis** · 18.03.2011, 14:57

Im Grunde ja, aber dafür hat man ja auch noch ein lokales Testsystem. Bevor ich etwas committe, sehe ich es mir in meinem lokalen Apache an. Da hab ich zwar vielleicht nicht die Millionen Datensätze große Live-Datenbank dran, sondern nur ein paar Testdatensätze oder ich arbeite lokal sogar mit einer Mock-Datenbank-Klasse.

**Thurial** · 18.03.2011, 15:05

Wär halt schön gewesen wenn es zuerst auf das Testsystem geht, und dann erst auf die Live Umgebung. Und das Testsystem sollte eben auch im Web sein und nicht lokal.
Was man dazu sagen sollte, alle arbeiten auf einem Terminalserver - das heisst keiner hat eigentlich eine lokale Umgebung.
Mal schauen, überleg grad ob ich nicht selber kurz einen Abgleich zwischen den zwei Webs bastel.

Aber danke schon einmal für deine prompte Antworten

**onemorenerd** · 18.03.2011, 16:50

Du musst SVN nicht selbst hosten. Es gibt Anbieter, die dir und deinem (kleinen) Team einen SVN-Server umsonst zur Verfügung stellen.

Du kannst das Updaten des Test- und auch des Live-System mit post-commit hooks oder Cronjobs automatisieren. Ich rate allerdings davon ab, das Testsystem nach jedem Commit zu aktualisieren. Da kommt man sich auch in kleinen Teams schnell ins Gehege. Entweder gibt es für jeden Entwickler ein eigenes Testsystem auf dem Server (auch das ist nur ratsam, wenn jeder in seinem Branch entwickelt) oder es testet erstmal jeder bei sich lokal.
Fürs Updaten des Test- und Live-Systems bieten sich Tags an.
Beispiel: Das Testsystem ist ein Checkout von /tags/testing/current und wenn es dort Änderungen gibt, aktualisiert es sich per svn up.
Willst du Änderungen testen, kopierst du /tags/testing/current nach /tags/testing/YYYYMMDDHHII und /trunk nach /tags/testing/current. Geht der Test in die Hose, kopierst du /tags/testing/YYYYMMDDHHII zurück nach /tags/testing/current.
Fürs Live-System analog mit /tags/production.

Team Entwicklungsumgebung