SVN sinnvoll nutzen

[Carsten Hölscher]

Seit Zusi mit 2 Verzeichnissen arbeiten kann, ergeben sich weitere Möglichkeiten eines SVN, wie es in Teilen der Bastlerschaft genutzt wird. Folgendes ist aus meiner Sicht zu empfehlen - es müßten aber auch mal SVN-Experten was dazu sagen.

- Bei einer Standardinstallation erzeugt Zusi ein Verzeichnis _ZusiData für (ggf. einstellbar in den Verwaltungseinstellungen) den offiziellen Datenstand. Dort ändert man als Anwender nichts, sondern installiert nur die offiziellen Addons.
- Das Datenverzeichnis (einstellbar in den Verwaltungseinstellungen) legt man auf das SVN-Verzeichnis.
- Im SVN liegt nicht der ganze offizielle Datenstand, sondern nur das was man aktiv baut. Die Zusi-Editoren legen alles was man modifiziert automatisch dort ab
- Geht ein Objekt in den offiziellen Stand, so wird es im SVN entfernt

Carsten

[Michael_Poschmann]

Das "Entfernen aus dem SVN" halte ich für keine gute Idee. Damit verliert man die Historie, die bisweilen mal wieder benötigt wird. Genau darin liegt ja der Nutzen des SVN. Versionierung.

Grüße
Michael

[MarkusEgger]

Das "Entfernen aus dem SVN" halte ich für keine gute Idee. Damit verliert man die Historie, die bisweilen mal wieder benötigt wird. Genau darin liegt ja der Nutzen des SVN. Versionierung.

Kann ich Michael nur zustimmen, damit führt man das SVN ad absurdum.


Edit: Noch dazu: Wie soll das sinnvoll bei Streckenmodulen laufen? Nach veröffentlichung auch rauswerfen aus dem SVN? Das ist Kamikaze!

Markus

[F. Schn.]

Ich würde da mal vorsichtig zustimmen: SVN ist nicht dafür gedacht, Dateien zu entfernen. Es müsste zwar gehen, aber eine eklige Angelegenheit sein. Bei Git will ich mich nicht zu weit aus dem Fenster lehnen, aber da sollte das trotz branch-Support eigentlich überhaupt nicht mehr gehen.

Der Vorteil ist allerdings, dass man nicht mehr alle Daten in ein SVN aufnehmen muss.

[MarkusEgger]

Hallo!

Mal so ein Gedanke:

Wäre nicht ein drittes Datenverzeichnis die Lösung? Da sollte das rein was fertig ist und auf Veröffentlichung wartet. Man sollte dort eine Datei reinkopieren können, dann wäre es super wenn die Verwaltung feststellen würde welche abhängigen Dateien nicht im offiziellen Bestand liegen (Datenverzeichnis 1) sondern im Baubestand (Datenverzeichnis 2) und die auch in diesen Datenbestand 3 rüberziehen (und idealerweise hierbei gleich noch bei Bedarf die .lsb anlegen). Dann müsste man in diesem Bestand die Strukturprüfungen etc. machen und könnte dort die zao generieren. Nach zao Generierung kann man die Dateien aus diesem Dritten Bestand guten Gewissens löschen, sie liegen ja archiviert im Baubestand.

Dass so eine Lösung nicht vom Himmel fällt ist auch klar, ich weiß jetzt auch auf die schnelle nicht ob ich was nicht berücksichtigt habe, aber so könnte es doch klappen die eigentlich gut gemeinten Funktionen der Verwaltung zur zao-Generierung auch im SVN-Umfeld zu nutzen, ohne die Steckenbauer in ihrer Flexibilität zu kastrieren?

Schön wäre es auch wenn dieser Datenbestand 3 schon mit der kompletten (derzeit offiziellen) Ordnerstruktur (aber ohne Inhalt) da wäre, bevor man was reinkopiert.

Markus

[Flo Zille]

In git ist es ohne Probleme möglich, innerhalb eines Commits auch Dateien zu entfernen (mit "git rm"), nicht nur hinzuzufügen oder zu verändern. Solange man nicht mit rebase o.ä. hantiert, um die Historie umzuschreiben, bleiben dabei auch alle älteren Commits unverändert, die vollständige Historie der bisherigen Commits dieser Datei bleibt also bestehen und kann jederzeit eingesehen / die Datei auf einem älteren Stand wiederhergestellt werden.

Wenn ich die Sache organisieren müsste, wäre der "offizielle Bestand" vielleicht ein git-repo mit Large File Storage. Wer etwas einreichen will, der dürfte einen Pull Request schicken. Vermutlich würden dann aber viele nichts mehr einreichen wollen, weil git-workflows generell vermutlich doch eher umständlich sind im Vergleich zum jetzigen Einreichungsablauf. Also ist es wohl besser, dass ich nicht für die Organisation zuständig bin.

[Carsten Hölscher]

Ich hätte gedacht dass man bei SVN eine Datei entfernen kann, ohne dass sie wirklich verloren geht - also dann man sie bei Bedarf wieder aktivieren kann.
Könnte man sie sonst alternativ in ein Archiv-Verzeichnis verschieben?
Eine automatische Konvertierung nach lsb könnte ich in den Add-On-Einreichen-Prozess übrigens noch einbauen. dann wär der Arbeitsschritt gleich erledigt.

Carsten

[F. Schn.]

Das entfernen ist sowohl in SVN wie auch in Git möglich. Das Problem ist aber, dass man dann bei der Wiederkehr der Datei die komplette Historie verliert, bei SVN kann man ein bisschen Hacken, damit man die wieder bekommt, bei Git dürfte das überhaupt nicht gehen. Die Workflows sind auf zwischenzeitlich verschwindende Daten eigentlich überhaupt nicht ausgerichtet. Man kann auch die Historie von zwischenzeitlich verschwundenen Dateien nur mit größerem Aufwand prüfen, und damit hat man auch größeren Aufwand, eine Datei wider herzustellen, wenn man sie einmal gelöscht hat. Wie gesagt: Geht, aber aufwendig.

Eine automatische Konvertierung nach lsb könnte ich in den Add-On-Einreichen-Prozess übrigens noch einbauen.

Es wäre gut, wenn sie im eigenen Bestand unverändert blieben, Zusi sie aber dennoch als "gleich" betrachtet, wenn sie nach einer "Konvertierung im Temp-Ordner" gleich sind. Das LSB-Datenformat hat gerade im Zusammenhang mit SVN und Git eigentlich nur Nachteile.

[MarkusEgger]

Hallo!

Es wäre gut, wenn sie im eigenen Bestand unverändert blieben, Zusi sie aber dennoch als "gleich" betrachtet, wenn sie nach einer "Konvertierung im Temp-Ordner" gleich sind.

Das wäre in der Tat ziemlich perfekt! habe aber keine Ahnung ob das machbar ist.

Markus

[Carsten Hölscher]

Ok, dann müßte man wohl sein Werk erstmal in ein Exportverzeichnis exportieren, dort die lsb-Konvertierung durchführen und aus diesem Verzeichnis heraus dann das Add-On-Einreichen durchspielen.
Der Verwaltung die lsb-Konvertierung beibringen und auf der Basis abgleichen wäre vermutlich auch möglioch. Das müßte ich mir mal anschauen. Wär dann aber erst was für die nächste Runde.

Carsten

[Max Senft]

Also bei SVN ist ein richtiges, endgültiges Löschen nur schwer möglich. Das normale SVN Delete "löscht" die Datei für die momentane Revision. Man kann ohne weiteres über den Repository Browser mittels Eingabe einer bestimmten Revisionsnummer den alten Stand wieder zurückholen. Und dann natürlich auch wieder einchecken.

Allerdings sehe ich tatsächlich SVN hier etwas falsch genutzt. Sinnvoller wäre es, wenn es das *trunk* Verzeichnis gibt, in dem der offizielle Bestand lebt. Soll an etwas gearbeitet werden, wird ein Branch erzeugt und dort gearbeitet. Sobald der Branch fertig und akzeptiert ist, werden die Änderungen zurück in den "trunk" übernommen und der Branch entweder einfach nur stillgelegt oder halt gelöscht.

Grüße
Max

[Carsten Hölscher]

Es muss halt ein Add-On-Umfang rausgezogen werden können mit der Verwaltung. Das dürfte mit den zwei Verzeichnissen so nicht gehen, da ja im trunk nicht alles gleichzeitig zur Veröffentlichung bereit ist.

Carsten

[Max Senft]

Hi,

na deswegen ja der Branch. Dort sind nur die Dateien drin, die geändert wurden/werden. Das ist dann ja letztendlich der Veröffentlichungsumfang?! Und sobald der Umfang "auslieferungsfertig" ist, lässt man ihn eben bestehen und verwendet ihn nur einfach nicht mehr.

Edit: Durch ein SVN Copy aus dem Branch in den trunk ergibt sich auch keine doppelte Dateispeicherung. Das funktioniert auf Metadaten-Ebene.

Gruß
Max

[Carsten Hölscher]

Das ist dann ja letztendlich der Veröffentlichungsumfang?!

Nein, nur eine Teilmenge davon wird geliefert. Es gibt m.E. hier 3 Datenstände
- der offizielle
- alle möglichen Bauvorhaben in diversen Stadien
- Bauvorhaben, die fertig zur Auslieferung sind

Carsten

[Max Senft]

Hi,

ja deswegen gibt es ja pro "Paketteil" einen eigenen Branch. Der ist dann entweder noch "Work in Progress" oder eben "Fertig/Ausgeliefert".

Sobald "Fertig", werden die Branch-Daten in den trunk rübergeholt, sodass ein Komplett-Setup auch alle Daten hat.

Es gibt dann halt entsprechend viele Branches. Aber selbst die kann man nochmal in Unterordner verschieben...

Man sollte in dem Fall von dem Gedanken abkommen in einem SVN-Branch mehrere Teilprojekte zu bearbeiten. "Nachteil" davon ist, dass man jeweils in Zusi das Arbeitsverzeichnis wechseln muss, je nachdem an was man denn arbeiten will.

Gruß
Max

[Carsten Hölscher]

OK, dann muss man für den Einreichen-Vorgang sein Datenverzeichnis auf das entsprechende Branch-Verzeichnis setzen, das offizielle ist ja eh "_ZusiData" und dann sollte genau das Richtige rauskommen.

Carsten

[Max Senft]

Hi,

klingt so, ohne mich jetzt in den Einreich-Abläufen auszukennen. :-)

Gruß
Max

[F. Schn.]

Man sollte in dem Fall von dem Gedanken abkommen in einem SVN-Branch mehrere Teilprojekte zu bearbeiten.

Dieses Verfahren ist machbar, wenn der Umfang von Teilprojekten beim branchen feststeht. Der Gedanke ist im Praktischen Zusi-Einsatz ein bisschen arg weit weg von der Umsetzbarkeit.

Der Verwaltung die lsb-Konvertierung beibringen und auf der Basis abgleichen wäre vermutlich auch möglioch. Das müßte ich mir mal anschauen. Wär dann aber erst was für die nächste Runde.

Das sehe ich als einzig realistische Vorgehensweise.

[Michael Springer]

klingt so, ohne mich jetzt in den Einreich-Abläufen auszukennen. :-)

Ich habe nach Alwins Weggang zuerst Meitingen/Westendorf eingereicht. Mein Gefühl damals war eine mittlere Quälerei ist noch untertrieben. Es sind/waren einfach zuviele händische Tricks und Hacks nötig, um aus einem SVN mit Geometrie gespeicherten .ls3 nach .lsb zu kommen und ein Veröffentlichungsreifes .zao zu kriegen. Die Verwaltung kann eine .ls3 -> .lsb Massenkonvertierung in einem Rutsch, was super ist, aber das macht man am Besten in einem andere Zusi-Verzeichnis als der trunk. Da die .lsb für die Projektweiterarbeit eh nicht gebraucht werden. Also musst den ganzen Mist erstmal in das andere Verzeichnis kriegen. Damals war auch noch das Problem mit dem AutorAufwand in jeder Zusi-Datei, so dass sich eigener und offizieller Bestand da auch immer noch unterschieden und Carstens Hash-Prüfung hunderte "false positiv" erkannte.

Was ich wirklich nervig finde: Für dieses Extra-Verzeichnis muss ich gefühlt 23x die Zusi-Datenverzeichnisse in der Verwaltung hin- und herschalten. Ich arbeite mit einem eingeschränktem Benutzerkonto und das geht nur mit Admin-Rechten. Also Dateiverwaltung starten, Mist vergessen mit Admin-Rechten zu starten, Menüpunkt Dateiverwaltung mit Adminrechten starten ausgewählt, Neustart, Passworteingabe, 1 Klick auf das zu setzende Verzeichnis. Dass das geänderte Verzeichnis von der Dateiverwaltung erkannt wird, muss man diese neu starten. Natürlich hat sie bei mir dann wieder nur eingeschränkte Benutzerrechte.
Mein Wusch wäre deshalb irgendwie: Könnte man diesen Pfad, der in der Registry gespeichert wird, nicht irgendwie an einen Platz in der Registry verschieben, den Zusi mit Benutzerrechten ändern kann?

Nach Meitingen/Westendorf haben wir bisher nichts größeres mehr eingereicht und die Idee im Team war, dass ich mich bevorzugt darum kümmere (da ich kein Händchen für 3D-Bau und Landschaft habe). Nach den ersten Erfahrungen habe ich absichtlich bei kleineren Dingen, wie Fahrplankorrektur oder sowas, die Team-Mitglieder das selber machen lassen, dass diese auch sehen, dass man dabei durch ein Tal der Schmerzen gehen kann. Im Schnitt brauchen wir 3-5 Versuche pro Einreichung, bis alles in der zao so ist, wie von Carsten gewünscht. Der Einreichvorgang ist leistbar (wenn man will auch ordentlich), aber er erfordert noch viel Zeit, Sitzfleisch und händisches Eingreifen. Zumindest in unserem SVN Team Süd Fall. Bei Anderen (z. B. Einzelkämpfern die direkt in .lsb bauen) sieht die Sachlage bestimmt wieder anders aus.

Thema Branch
Ich bin da nicht so SVN sattelfest, habe aber das Gefühl, dass das mit den Branches nicht so einfach geht.
Folgendes Beispiel:
Alles Fertige ist im Trunk.
Team Mitglied 1 macht einen Branch Nordendorf, weil er da Landschaft baut. Der Landschaftsbau sagen wir mal dauert 3-4-5 Monate.
Im Forum kommt eine Kastastrophenmeldung zu Westendorf.
Ich stelle fest, dass Westendorf tatsächlich einen Fehler hat, der zur Folge hat, dass ich die Fahrstraßen neu machen muss.
Der Kollege im Branch Nordendorf hat weitere Streckenelemente in die .st3 eingefügt zum Straßenbauen.
Wie erreiche ich nach dem Laden von Westendorf aus dem Trunk für mein Fahrstraßen neu erzeugen, die richtige Nordendorf.st3 im Branch und nicht die aus dem trunk? Die Module sind ja untereinander Vernetzt.

Wir wollen ja trotzdem eine fahrbare Version der Gesamtstrecke zum Testen haben. Oder kann ich diese Westendorf Reparatur erst durchführen, wenn die fertige Nordendorf-Landschaft nach 4 Monaten wieder im trunk ist?
Ich denke Zusi tickt von der Bauweise her ein bischen anders, als gewöhnliche Softwareprodukte, wo dieses Branchen leichter möglich ist.

Ich habe noch mehr Gedanken, aber das reicht jetzt erstmal.

Michael

[Juergen_Verheien]

Hallo,

warum wird die Lösung des Problems wieder so kompliziert diskutiert.

In der jetzigen Form wird gegen Ende der Aktivitäten der Button "Fertigstellen" gezeigt.

Ich vermute, dass nach Betätigen des Buttons eine Prozedur auf den Ordner "owndata" zugreift, und mit den dort hinterlegten Daten das verschlüsselte zao-file erstellt wird.

Vorschlag:

Bis zum Button "Fertigstellen" bleibt der Vorgang unverändert.

Danach der Button "Fertigstellen" und "Daten bearbeiten"

Bei "Fertigstellen" fortfahren der vorhandenen Prozedur, bei "Daten bearbeiten" Sprung mit dem WIN-Explorer in den Ordner "owndata". Dort die erforderlichen Korrekturen vornehmen, mit dem neuen Button "Bearbeitung beenden " die vorhandene Prozedur für die Bildung des zao-file, die nun auf den neuen Inhalt von "owndata" zugreift, im Hintergrund aufrufen und ausführen.