Ich verlagere das mal hierher.Carsten Hölscher hat geschrieben:so ein System hätte sicherlich viele Vorteile. Um es den potentiellen Nutzern näherbringen zu können, wären sicherlich detailliertere Infos nötig, wie genau das in der Praxis abläuft (auch nach dem Gespräch mit Roland wäre mir das für den Anwendungsfall Zusi-Objekte mit vielen Nutzern noch nicht ganz klar).
Vielleicht könnte ja einer der Experten mal so etwas mit allen Bearbeitungsschritten und der einzurichtenden Umgebung skizzieren.
Als ersten Ansatz zum näheren Ablauf kann man Olis Tutorial nehmen, wobei man den Secure Shell Teil einfach weglässt, denn der verwirrt m.E. zunächst mehr als das er hilft. (Ich hoffe, Oli sieht das auch so
)Es sind aus meiner Sicht zwei unterschiedliche Aspekte zu betrachten. Das eine ist der handwerkliche Umgang damit. Das ist technisch recht schnell erlernbar, führt aber dann sicher auch zu einer anderen Arbeitsweise.
Und das ist der andere Aspekt: Was will man mit dem Versionsmanagement erreichen (Vereinheitlichung, kein Wildwuchs mehr, Konsistenz, Backup, Release-Verwaltung, einfachere Organisation der rbeitsumgebung etc.)?
Hier ein einfaches Szenario:
- Gegeben sei der Fst der BR 12345 für Zusi 2.3. Gewünscht ist ein Vorgehen in Schritten, um zunächst Basisfunktionalität für 2.4 zu erreichen und später auch die neuen Features zu nutzen.
- Zu jedem Zeitpunkt will ich einen lauffähigen Fst haben.
- Ich will mich nicht mit der Organisation von Sicherungskopien, 3 oder mehr verschiedenen Directories, die alle mehr oder weniger dasselbe erhalten, und deren Verwaltung rumschlagen.
- Der Fst liegt im Repository unter Schirmherrschaft des ZPA. Von dort ist auch die Directory-Strutur vorgegeben.
- Die aktuelle Release wird im Repository auf den Fst-Files in der Directory-Struktur gekennzeichnet mitz einem "sticky tag". Auf diese Release kann man jederzeit zurückgreifen.
- Ich fange an zu basteln, in dem ich die Files verändere, lokal bei mir, in meiner Arbeitsumgebung (Checkout). Das, was fertig und mehr oder minder getestet ist, übertrage ich wieder ins Repository (Commit).
- Das ZPA stellt fest, es ist großer Mist, und macht ein paar Änderungen, indem es sich selbst den FST auscheckt, auf die gerade committete Version updatet (
) diese anpasst und es wieder zurück ins Repository schickt. - Ich bin der Arbeit des ZPA - ganz ausnahmsweise - nicht zufrieden, und mache noch ein paar weitere Anpassungen.
- Irgendwann sind alle Klarhieiten beseitigt, und die neue Version wird akzeptiert und erneut als Release getaggt.
- Während der langwierige Abnahmeprozess noch lief, hatte ich tolle Ideen für die Nachtansicht und wollte damit sofort anfangen. Drum nahm ich die gerade aktuelle Zwischenversion (ohne Tag), die ja nach eigener Ansicht schon überperfekt war, und verzweigte in einen eigenen Entwicklungsast, eine Branch. Auch die bekommt eine Kennzeichnung, den Branchnamen.
- Meine tägliche Arbeit am Nachtleben findet in dieser Branch statt, auch dort wächst und gedeiht es, mit immer neuen Zwischenversionen.
- Falls ich zwischendurch nochmal durch das ZPA unterbrochen werde, um irgendwas zu klären oder zu verändern, wechsle ich temporär auf den Hauptstamm (Trunk) zurück.
- Nachdem nun auch meine Nachtversion jenseits jeder Kritik angelangt ist, wird die vorher erstellte Release erneut aktualisiert, die Branch wird in den Trunk gemerged.
- Dabei kann es zu Konflikten kommen, wenn Widersprüchliches in Trunk und Branch gemacht wurden. Da hatte der Fahrschalter im Trunk nur 34 Stufen. Damit wurde die Branch gestartet. Später kam im Trunk eine Stufe dazu. Konfliktfrei bleibt es, wenn ich diesen Eintrag (immer auf den Text des Files bezogen) nicht auch in der Branch verändere. Wenn ja, muss ich es von Hand reparieren, sonst macht das Merge das automatisch.
- Wieviele verschiedene Varianten des Fst-Files hab ich während der ganzen Entwicklung bei mir zu Hause? Immer nur eine einzige. Wieviele hat das ZPA? Auch immer nur eine. Wieviele stehen im Repository? Alle, aber alle im selben File.
- Wieviele ZIPs und ZAD-Mails gingen während des Prozesses hin und her und mussten jeweils erstellt und an die richtige Stelle ausgepackt werden? Keine einzige.
. Deswegen ist das Angebot von Oli so interessant. 
) egal. Auch lauffähig oder compilierbar müssen die Sourcen nicht sein.