SVN sinnvoll nutzen
- Michael_Poschmann
- Beiträge: 19880
- Registriert: 05.11.2001 15:11:18
- Aktuelle Projekte: Modul Menden (Sauerland)
- Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)
Re: SVN sinnvoll nutzen
Hallo Jürgen,
mir ist nicht klar, was mit "erforderliche Korrekturen" gemeint sein könnte.
Den Automatismus hat Carsten doch bewusst so angelegt, dass er ohne Nutzereingriff durchläuft.
Grüße
Michael
mir ist nicht klar, was mit "erforderliche Korrekturen" gemeint sein könnte.
Den Automatismus hat Carsten doch bewusst so angelegt, dass er ohne Nutzereingriff durchläuft.
Grüße
Michael
- Carsten Hölscher
- Administrator
- Beiträge: 33436
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Wenn Dateien gefunden wurden, von denen man aber sicher weiß, dass sie nicht mitgeleifert weden sollen, so kann man das ja im Laufes des "Einreichen"-Durchlaufs festlegen.
Carsten
Carsten
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Aus der Sicht eines "SVN-Experten" hat Max das entscheidende schon gesagt: Branches. Denn im Prinzip ist dieser Workflow bereits erfunden und in SVN integriert.
Der Use-Case eigenes Bauprojekt sieht doch so aus, wenn ich das richtig verstehe:
Der Use-Case eigenes Bauprojekt sieht doch so aus, wenn ich das richtig verstehe:
- Basis ist der offizielle Bestand.
- Man fügt neue Objekte hinzu.
- Ggf ändert man auch bisherige Objekte.
- Nur die neuen und geänderten Objekte werden eingereicht.
- Der offizielle Bestand wandert ins SVN, komplett, als Trunk.
- Für das eigene Projekt erzeugt man eine Bau-Branch, komplett, von der Wurzel beginnend. Und die checkt man separat aus. Dann hat man lokal zwei komplette Bäume, die zunächst identisch sind. Auf SVN-Repo-Server-Seite ist noch nicht viel passiert, denn wie Max schon richtig gesagt hat, findet das da auf Meta-Ebene statt.
- Alle eigene Ergänzungen und Änderungen führt man ausschließlich in der eigenen Bau-Branch durch. Dadurch weichen SVN-Trunk (offizieller Bestand) und SVN-Branch (eigene Werke) allmählich voneinander ab.
- Jetzt möchte man sein Projekt einreichen, natürlich nur das, was neu ist oder sich geändert hat, aber mit vollständigen Verzeichnisbaum. Dazu legt man eine weitere Branch an, wieder aus dem Trunk abgeleitet und nennt sie z.B. Einreich-Datum-xxx-Branch. Die hat damit also zu Beginn wieder nur den offiziellen Stand. Diese Einreich-Branch checkt man ebenfalls aus
- Auf diese Einreich-Branch führt man jetzt ein SVN-Merge durch, mit der Bau-Branch als Quelle. SVN stellt fest, was sich geändert hat und wird dieses Wissen im Repo festhalten.
- Nun schaut man sich für die Einreich-Branch die Historie an und ruft zu dem Merge-Commit den Dialog für geänderte Dateien auf. Über das Kontext-Menü kann man diese als Change Tree irgendwohin exportieren. Man erhält einen vollständigen Verzeichnisbaum, aber als Dateien nur die, die neu oder geändert sind. Diesen Change-Tree reicht man ein.
- Die Working-Copy der Einreich-Branch kann man anshcließend wieder löschen. Diese Branch wird nicht wieder benutzt. Für den nächsten Einreich-Meilenstein legt man eine neue Branch an.
- Was passiert, wenn sich der offizielle Bestand zwischenzeitlich ändert? Die Aktualisierungen lässt man ganz normal auf seinen lokalen offiziellen Bestandsbaum los. Da dieser Baum aber gleichzeitig den Trunk des eigenen SVN darstellt, führt man nach der Aktualisierung ein Commit durch, und das Repo ist dann auch wieder aktuell. Das ist auch der Grund, die Einreich-Baanch erst dann zu erzeugen, wenn man wirklich was einreichen will. Die Einreich-Branch ist dann nämlich aktuell und der Vergleich mit der Bau-Branch, manifestiert im Merge, eben auch.
Zuletzt geändert von Roland Ziegler am 05.04.2020 11:24:25, insgesamt 1-mal geändert.
- Carsten Hölscher
- Administrator
- Beiträge: 33436
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Und das macht man dann für jedes einzelne Objekt? Also jedes Streckenmodul oder jedes Fahrzeug?Der Use-Case eigenes Bauprojekt sieht doch so aus, wenn ich das richtig verstehe:
Carsten
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Das kann man halten wie man möchte. Wenn man z.B. ein Riesenprojekt hat, was über mehre Jahre geht, aber zwischendurch ein kleines, was nur wenige Objekt umfasst, das größere das kleinere aber nutzt, und das kleinere aber zuerst eingereicht wird, dann würde ich zwei Bau-Branches machen, eine für das große Projekt, die andere für das kleine. Vor allem kann man die zweite Branch ja aus er ersten ableite, zu einem beliebigen Zeitpunkt.
Merged man dann in die Einreich-Branch, kann sich dank SVN herausstellen, dass es doch ein paar mehr Objekte sind.
Letztlich sind das nur Variationen der üblichen Konventionen "Development"- und "Release"-Branch.
Merged man dann in die Einreich-Branch, kann sich dank SVN herausstellen, dass es doch ein paar mehr Objekte sind.
Letztlich sind das nur Variationen der üblichen Konventionen "Development"- und "Release"-Branch.
-
- Beiträge: 3195
- Registriert: 07.03.2002 10:09:59
- Aktuelle Projekte: Objektbau und Modulgestaltung
- Wohnort: Dortmund
Re: SVN sinnvoll nutzen
Hallo Carsten,
Wie und wo kann man diese Dateien denn festlegen ?Wenn Dateien gefunden wurden, von denen man aber sicher weiß, dass sie nicht mitgeleifert weden sollen, so kann man das ja im Laufes des "Einreichen"-Durchlaufs festlegen.
Carsten
tschüs....
Jürgen
Jürgen
- Michael Springer
- Beiträge: 2930
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: SVN sinnvoll nutzen
Roland schlägt vor
- eine Kirche.ls3 und eine Kirche.lsb
- also das wandert in den Trunk
Wo lagere ich dann meine Kirche.ls3 mit XML-Gemetriedaten? In der ich z.b. Fehlerorrekturen nach Meldung aus dem Forum vornehme?
Ich kann doch keine 2 verschiedenen Dateien mit gleichem Namen im trunk haben.
Wenn die .ls3 Geometrien nur im Branch gelagert werden? Dann muss ich immer sicherstellen, dass bei der Übernahme in den trunk die .lsb Konvertierung korrekt ausgeführt wurde.
Oder sehe ich das falsch?
Michael
Im offiziellen Bestand gibt es z.B.Der offizielle Bestand wandert ins SVN, komplett, als Trunk.
- eine Kirche.ls3 und eine Kirche.lsb
- also das wandert in den Trunk
Wo lagere ich dann meine Kirche.ls3 mit XML-Gemetriedaten? In der ich z.b. Fehlerorrekturen nach Meldung aus dem Forum vornehme?
Ich kann doch keine 2 verschiedenen Dateien mit gleichem Namen im trunk haben.
Wenn die .ls3 Geometrien nur im Branch gelagert werden? Dann muss ich immer sicherstellen, dass bei der Übernahme in den trunk die .lsb Konvertierung korrekt ausgeführt wurde.
Oder sehe ich das falsch?
Michael
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Den Trunk selbst würdest Du nicht anfassen, da sollte nur der Zusi-Updater hineinschreiben, und Du das dann comitten (entschuldige den Sprachmix, aber die Begriffe sind im Englischen eindeutiger als im Deutschen).Michael Springer hat geschrieben:Wenn die .ls3 Geometrien nur im Branch gelagert werden? Dann muss ich immer sicherstellen, dass bei der Übernahme in den trunk die .lsb Konvertierung korrekt ausgeführt wurde.
Aber die Einreich-Branch ist betroffen. Und da würde bei Änderungen von .ls3 fehlende Aktualisierung von .lsb in der Tat nicht erkannt. Aber bei neu hinzukommenden Objekten ist das doch genauso. Eine fehlende .lsb kann SVN natürlich nicht feststellen, weil es die Anwendungsdomäne nicht kennt. Irgendwas soll die Zusi-Verwaltung ja auch noch zu tun haben - falls sie so etwas untersucht.
- Michael Springer
- Beiträge: 2930
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: SVN sinnvoll nutzen
Das ist sicherlich nicht der Weisheit letzter Schluss, aber ich könnte mir einen gangbaren Weg etwa so vorstellen:
- Ich möchte einen Fahrplan (oder irgendwas) einrichen.
- Ich wähle in der Dateiverwaltung die *.fpn aus
- Die Dateiverwaltung erkennt alle Änderungen (auch die in der *.fpn verlinkten Dateien, wie geänderte Streckenmodule und Objekte) und kopiert diese Dateien in ein separates Datenverzeichnis
- Die Dateiverwaltung wandelt während des Kopiervorgangs gleich die Geometrie der *.ls3 Dateien in *.ls3/*.lsb um
- Die Dateiverwaltung prüft vor dem Schreiben der *.ls3/*.lsb auf Platte, ob die erzeugte *.ls3/*.lsb gleich der Variante in _ZusiData ist. Wenn ja, garnicht auf Platte schreiben, weil redundant
Dann müssten alle einzureichenden Daten im separaten Datenverzeichnis bereits in der richtigen *.lsb Form vorliegen.
- Ich packe wie bisher mein Addon mit Carstens Routine aus dem separaten Datenverzeichnis
So wäre das für meine Gedankenwelt relativ einfach zu handhaben. Ich hoffe ich habe nichts Wichtiges vergessen. Das einzigste was man der Dateiverwaltung beibringen müsste, wäre das Umkopieren in ein separates Verzeichnis und eine on-the-fly lsb Konvertierung und Prüfung, ob das abweichend zu _ZusiData ist.
Michael
- Ich möchte einen Fahrplan (oder irgendwas) einrichen.
- Ich wähle in der Dateiverwaltung die *.fpn aus
- Die Dateiverwaltung erkennt alle Änderungen (auch die in der *.fpn verlinkten Dateien, wie geänderte Streckenmodule und Objekte) und kopiert diese Dateien in ein separates Datenverzeichnis
- Die Dateiverwaltung wandelt während des Kopiervorgangs gleich die Geometrie der *.ls3 Dateien in *.ls3/*.lsb um
- Die Dateiverwaltung prüft vor dem Schreiben der *.ls3/*.lsb auf Platte, ob die erzeugte *.ls3/*.lsb gleich der Variante in _ZusiData ist. Wenn ja, garnicht auf Platte schreiben, weil redundant
Dann müssten alle einzureichenden Daten im separaten Datenverzeichnis bereits in der richtigen *.lsb Form vorliegen.
- Ich packe wie bisher mein Addon mit Carstens Routine aus dem separaten Datenverzeichnis
So wäre das für meine Gedankenwelt relativ einfach zu handhaben. Ich hoffe ich habe nichts Wichtiges vergessen. Das einzigste was man der Dateiverwaltung beibringen müsste, wäre das Umkopieren in ein separates Verzeichnis und eine on-the-fly lsb Konvertierung und Prüfung, ob das abweichend zu _ZusiData ist.
Michael
Zuletzt geändert von Michael Springer am 06.04.2020 09:47:10, insgesamt 1-mal geändert.
- Michael_Poschmann
- Beiträge: 19880
- Registriert: 05.11.2001 15:11:18
- Aktuelle Projekte: Modul Menden (Sauerland)
- Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)
Re: SVN sinnvoll nutzen
Hallo Namensvetter,
das ist auch der Weg, denn ich gestern - manuell - durchgeführt habe. Von daher meine Unterstützung.
Grüße
Michael
das ist auch der Weg, denn ich gestern - manuell - durchgeführt habe. Von daher meine Unterstützung.
Grüße
Michael
- MarkusEgger
- Beiträge: 745
- Registriert: 10.11.2001 22:38:17
- Aktuelle Projekte: Augsburg-Donauwörth
- Wohnort: Augsburg
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Hallo!
Ja, auch von mir maximale Zustimmung. Dem SVN Weg traue ich erst wenn einer das wirklich mal für ein Zusi-Projekt durchexerziert hat. Es ist ja am Anfang beim bauen nicht mal irgendwie klar in welcher Abhängigkeit was irgendwann mal veröffentlicht wird... Wir entscheiden uns erst etwa zwei Monate vorher, wann wir ein Streckenupdate wirklich planen und aus welchen Modulen (und anderen Objekten) es bestehen wird. Erst dann ist absehbar ob es in einem Modul Abhängigkeiten zu irgendwelchen Teilaspekten gibt die nicht bis dahin lösbar sind, weil irgendwas nicht fertig wird oder grade gar keine Lösung parat ist usw.
Markus
Ja, auch von mir maximale Zustimmung. Dem SVN Weg traue ich erst wenn einer das wirklich mal für ein Zusi-Projekt durchexerziert hat. Es ist ja am Anfang beim bauen nicht mal irgendwie klar in welcher Abhängigkeit was irgendwann mal veröffentlicht wird... Wir entscheiden uns erst etwa zwei Monate vorher, wann wir ein Streckenupdate wirklich planen und aus welchen Modulen (und anderen Objekten) es bestehen wird. Erst dann ist absehbar ob es in einem Modul Abhängigkeiten zu irgendwelchen Teilaspekten gibt die nicht bis dahin lösbar sind, weil irgendwas nicht fertig wird oder grade gar keine Lösung parat ist usw.
Markus
Der Blog zum Streckenbauprojekt Augsburg-Donauwörth:
http://www.zusi-team-sued.de
http://www.zusi-team-sued.de
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Der entscheidende Punkt ist halt Erfahrung und Übung. Für den professionellen ITler ist dergleichen SVN-Nutzung (oder Git udgl.) de facto Grundlage des Geschäfts, täglich Brot und kalter Kaffee. Aber auch der ITler hatte natürlich mal eine Lernkurve.MarkusEgger hat geschrieben:Dem SVN Weg traue ich erst wenn einer das wirklich mal für ein Zusi-Projekt durchexerziert hat.
Die üblichen Annäherungsschritte des Nutzers an die Funktionalität eines Repositories sind:
- Verteilung
- Historisierung
- Verzweigung
- MarkusEgger
- Beiträge: 745
- Registriert: 10.11.2001 22:38:17
- Aktuelle Projekte: Augsburg-Donauwörth
- Wohnort: Augsburg
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Hallo!
Mir wäre deutlich wohler wenn das jemand sagen würde der tatsächlich Zusi3-Streckenbau betreibt. Im Moment haben wir eine etwas komische Diskussion:
SVN-Profis ohne Zusi3-Streckenbauerfahrung sagen: Macht das so!
Zusi-Streckenbauer sagen: So klappt das nicht!
Wir Streckenbauer wollen eigentlich Strecke bauen und uns nicht stundenlang in technische Lösungen einarbeiten um dann hinterher festzustellen, dass die "Theoretiker" (nicht böse verstehen, ist nicht so gemeint) Zusi-spezifische Eigenheiten nicht kannten oder ihnen zumindest keine Bedeutung zuwiesen. Zusi-Streckenbau ist nicht Software-Programmierung. Ich bin erst bereit mich in Branches und sonstiges reinzudenken wenn jemand der schon Zusi3-Streckenmodule ausgeliefert hat sagt, ja das geht so und ist eine praktikable Lösung.
Ich kenne nur einen dem ich tiefere SVN-Kenntnisse zutraue und der definitiv Zusi3-Streckenbau-Erfahrung hat, das ist Alwin, vielleicht mag er ja ausnahmsweise doch eine Einschätzung hierzu abgeben.
SVN ist für uns Bastler bisher fast nur eine wunderbare Datensicherung und eine Möglichkeit gemeinsam an Dateien zu arbeiten. Und ich bin schon heilfroh wenn ich als reiner PC-Anwender diese Funktionalitäten halbwegs beherrsche. Wir müssen wirklich schauen, dass Steckenbau (und Objektbau) nicht so kompliziert wird, dass jeder den Aufwand scheut. Und wir Bastler wollen eigentlich in der raren Zeit basteln - und nicht administrieren.
Markus
Mir wäre deutlich wohler wenn das jemand sagen würde der tatsächlich Zusi3-Streckenbau betreibt. Im Moment haben wir eine etwas komische Diskussion:
SVN-Profis ohne Zusi3-Streckenbauerfahrung sagen: Macht das so!
Zusi-Streckenbauer sagen: So klappt das nicht!
Wir Streckenbauer wollen eigentlich Strecke bauen und uns nicht stundenlang in technische Lösungen einarbeiten um dann hinterher festzustellen, dass die "Theoretiker" (nicht böse verstehen, ist nicht so gemeint) Zusi-spezifische Eigenheiten nicht kannten oder ihnen zumindest keine Bedeutung zuwiesen. Zusi-Streckenbau ist nicht Software-Programmierung. Ich bin erst bereit mich in Branches und sonstiges reinzudenken wenn jemand der schon Zusi3-Streckenmodule ausgeliefert hat sagt, ja das geht so und ist eine praktikable Lösung.
Ich kenne nur einen dem ich tiefere SVN-Kenntnisse zutraue und der definitiv Zusi3-Streckenbau-Erfahrung hat, das ist Alwin, vielleicht mag er ja ausnahmsweise doch eine Einschätzung hierzu abgeben.
SVN ist für uns Bastler bisher fast nur eine wunderbare Datensicherung und eine Möglichkeit gemeinsam an Dateien zu arbeiten. Und ich bin schon heilfroh wenn ich als reiner PC-Anwender diese Funktionalitäten halbwegs beherrsche. Wir müssen wirklich schauen, dass Steckenbau (und Objektbau) nicht so kompliziert wird, dass jeder den Aufwand scheut. Und wir Bastler wollen eigentlich in der raren Zeit basteln - und nicht administrieren.
Markus
Der Blog zum Streckenbauprojekt Augsburg-Donauwörth:
http://www.zusi-team-sued.de
http://www.zusi-team-sued.de
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Nun, worin unterscheidet sich denn ein Zusi-Bauprojekt von einem Projekt aus anderen Anwendungsdomänen? Abstrakt betrachtet, durch spezifische Datei-Bearbeitungsverfahren der besagten Anwendungsdomäne.MarkusEgger hat geschrieben:SVN-Profis ohne Zusi3-Streckenbauerfahrung sagen: Macht das so!
Zusi-Streckenbauer sagen: So klappt das nicht!
Hier wurde von Michael Springer das Beispiel .ls3/.lsb genannt. Aber das ist nicht wirklich spezifisch im Sinne von SVN nicht anwendbar.
Im typischen IT-Softwareumfeld hat man es mit Quellcode-Dateien zu tun, die ins Repository wandern. Ein Teil solcher Dateien wird heutzutage aber generiert, z.B. auf der Basis von Metadaten, die vielleicht als XML hinterlegt sind. Und dann gibt es da irgendwo einen Code-Generator, der aus so einem XML eine oder mehrere andere Dateien erzeugt, ohne die nachher kein Compiler laufen kann.
Analogie: ls3 = XML, lsb = generierter Code, Zusi-Entwicklungs- und Verwaltungswerkzeuge = Code-Generator, Zusi-Laufzeitumgebung = Compiler.
- MarkusEgger
- Beiträge: 745
- Registriert: 10.11.2001 22:38:17
- Aktuelle Projekte: Augsburg-Donauwörth
- Wohnort: Augsburg
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Hallo!
- Das Projekt ist anfangs und auch zwischendrin nicht klar umrissen
- Das Projekt wird von PC-Anwendern ohne jegliche Administrations- oder Programmierkenntnisse betrieben.
Ihr SVN-Profis müsst bitte verstehen, dass viele von uns Bastlern bei Laufzeitumgebung, Compiler, generierter Code zum lesen aufhören. Ich habe Landschaftsdateiern, Texturen usw. und die will ich möglichst einfach zu Carsten zur Veröffentlichung bringen. Diese ganze Diskussion hat so einen belehrenden Charakter: Ihr Bastler nutzt bitte SVN richtig, dann ist alles gut. Das nervt mich massiv. Wer von Euch hängt sich denn mal ein paar Stunden (eher Tage) rein und setzt das für eines der SVNs richtig auf und tut für ein Projekt mal tatsächlich so einen Einreichungsvorgang durchexerzieren?
Markus
Es unterscheidet sich durch noch viel mehr:Nun, worin unterscheidet sich denn ein Zusi-Bauprojekt von einem Projekt aus anderen Anwendungsdomänen? Abstrakt betrachtet, durch spezifische Datei-Bearbeitungsverfahren der besagten Anwendungsdomäne.
- Das Projekt ist anfangs und auch zwischendrin nicht klar umrissen
- Das Projekt wird von PC-Anwendern ohne jegliche Administrations- oder Programmierkenntnisse betrieben.
Ihr SVN-Profis müsst bitte verstehen, dass viele von uns Bastlern bei Laufzeitumgebung, Compiler, generierter Code zum lesen aufhören. Ich habe Landschaftsdateiern, Texturen usw. und die will ich möglichst einfach zu Carsten zur Veröffentlichung bringen. Diese ganze Diskussion hat so einen belehrenden Charakter: Ihr Bastler nutzt bitte SVN richtig, dann ist alles gut. Das nervt mich massiv. Wer von Euch hängt sich denn mal ein paar Stunden (eher Tage) rein und setzt das für eines der SVNs richtig auf und tut für ein Projekt mal tatsächlich so einen Einreichungsvorgang durchexerzieren?
Markus
Der Blog zum Streckenbauprojekt Augsburg-Donauwörth:
http://www.zusi-team-sued.de
http://www.zusi-team-sued.de
- Michael Skupin
- Beiträge: 196
- Registriert: 01.09.2015 23:35:28
- Aktuelle Projekte: Team Süd Strecke Augsburg - Donauwörth
- Wohnort: Schmiechen
Re: SVN sinnvoll nutzen
Hallo Leute!
Frage:
Braucht Zusi -> SVN etc. ? NEIN
Braucht man zum Paket schnüren ein SVN? NEIN
Wer das SVN bis zum letzten Bit ausnutzen möchte, kann das ja machen.
Carsten hat ein Tool geschaffen das sich DATEIVERWALTUNG nennt, in dem man inzwischen vieles machen kann, auch .zao Paket schnüren.
Und das braucht auch kein SVN, egal ob als Einzelkämpfer oder als Team.
Der Vorschlag von Michael Springer,
Ich bin der Meinung das Carsten diesen Gedanken entsprechend Umsetzen kann.
Die Dateiverwaltung ist ein mächtiges Tool , das wie jedes andere Zusi Programm, mit den Anforderungen wächst und weiter wachsen wird.
Es sollte aber unabhänig sein von irgendwelchen Fremdtools.
Und es gibt nicht nur ITler, und selbst wenn, nicht alle benutzen SVN/Github.
Und einen Nicht ITler zu sagen: "wenn du Pakete bauen willst, musst du SVN studieren", ist völlig overdressed
Der wird euch was Husten
Frage:
Braucht Zusi -> SVN etc. ? NEIN
Braucht man zum Paket schnüren ein SVN? NEIN
Wer das SVN bis zum letzten Bit ausnutzen möchte, kann das ja machen.
Carsten hat ein Tool geschaffen das sich DATEIVERWALTUNG nennt, in dem man inzwischen vieles machen kann, auch .zao Paket schnüren.
Und das braucht auch kein SVN, egal ob als Einzelkämpfer oder als Team.
Der Vorschlag von Michael Springer,
ist in meinen Augen sinnvoll und sicherlich machbar. Michael Poschmann hat diesen Gedanken mit positiven feedback bestätigt.Michael Springer hat geschrieben:..... aber ich könnte mir einen gangbaren Weg etwa so vorstellen:
- Ich möchte einen Fahrplan (oder irgendwas) einrichen.
- Ich wähle in der Dateiverwaltung die *.fpn aus
- Die Dateiverwaltung erkennt alle Änderungen (auch die in der *.fpn verlinkten Dateien, wie geänderte Streckenmodule und Objekte) und kopiert diese Dateien in ein separates Datenverzeichnis
- Die Dateiverwaltung wandelt während des Kopiervorgangs gleich die Geometrie der *.ls3 Dateien in *.ls3/*.lsb um
- Die Dateiverwaltung prüft vor dem Schreiben der *.ls3/*.lsb auf Platte, ob die erzeugte *.ls3/*.lsb gleich der Variante in _ZusiData ist. Wenn ja, garnicht auf Platte schreiben, weil redundant
Dann müssten alle einzureichenden Daten im separaten Datenverzeichnis bereits in der richtigen *.lsb Form vorliegen.
- Ich packe wie bisher mein Addon mit Carstens Routine aus dem separaten Datenverzeichnis
.......
Das einzigste was man der Dateiverwaltung beibringen müsste, wäre das Umkopieren in ein separates Verzeichnis und eine on-the-fly lsb Konvertierung und Prüfung, ob das abweichend zu _ZusiData ist.
Ich bin der Meinung das Carsten diesen Gedanken entsprechend Umsetzen kann.
Die Dateiverwaltung ist ein mächtiges Tool , das wie jedes andere Zusi Programm, mit den Anforderungen wächst und weiter wachsen wird.
Es sollte aber unabhänig sein von irgendwelchen Fremdtools.
Und es gibt nicht nur ITler, und selbst wenn, nicht alle benutzen SVN/Github.
Und einen Nicht ITler zu sagen: "wenn du Pakete bauen willst, musst du SVN studieren", ist völlig overdressed
Der wird euch was Husten
Alles Wissenwertes und Info´s gibt es auf unserm Blog:
http://www.zusi-team-sued.de
Unsere original Strecken( Bau )Objekte:
https://gallerie.zusi-team-sued.de/index.php
Das Team freut sich auf euren Besuch
http://www.zusi-team-sued.de
Unsere original Strecken( Bau )Objekte:
https://gallerie.zusi-team-sued.de/index.php
Das Team freut sich auf euren Besuch
- Max Senft
- Administrator
- Beiträge: 3004
- Registriert: 04.11.2001 14:01:40
- Aktuelle Projekte: Dies und das
- Wohnort: Blieskastel, Saarland, Deutschland
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Hi,
also ich bin hochgradig verwirrt, muss ich ganz ehrlich sagen.
Ich gebe Markus Recht, dass wir hier aufpassen müssen, entweder mit zu abstrakten Beispielen oder mit nicht transferierten Beispielen zu hantieren.
Ich gebe aber auch Roland Recht, dass SVN die anfallenden Aufgaben eigentlich gut handhaben sollte.
Auf jeden Fall kommen wir nicht darum, um SVN-spezifische, teils englische, Begriffe zu verwenden. Es lebe die gemeinsame Begriffe-Basis! :-)
Was ich im Moment nicht verstehe: Geht es hier um das große, Haupt-Zusi-SVN-Repository auf das auch Bastler zugreifen oder geht es ggf. auch um private SVN-Repositories?
Ein kleiner interdisziplinärer Ausflug:
Angenommen es geht um ersteres, also alle Bastler greifen auf das Haupt-Zusi-SVN-Repository zu. Um es nicht direkt zu kompliziert zu machen: Das besteht aus dem "trunk" in dem die Inhalte gespeichert sind, die auch ausgeliefert werden. Für einen Moment bitte erstmal annehmen, dass es keine unterstützenden Dateien gibt, wie Pläne oder sonst irgendwas, was vielleicht auch im SVN enthalten sein soll. Diese Daten liegen letztendlich auch bei jedem im "_ZusiData" Verzeichnis.
Soll nun ein Teil des bestehenden Zusi-Datenumfangs geändert werden, wird man ja vermutlich die entsprechende Datei öffnen, verändern und wieder abspeichern. Durch die Zusi-Mechanismen landet das dann nicht in diesem ersten ("offizielle Daten") Zusi-Verzeichnis, sondern im zweiten Zusi-Verzeichnis.
Diese Aktion übertragen auf ein SVN würde bedeuten, dass nicht direkt die Datei geöffnet wird, sondern ein Branch der Datei/des Ordners/einer ganzen Unterordnerstruktur/der kompletten Ordnerstruktur aus dem trunk (1. Verzeichnis) in das branch Verzeichnis (2. Verzeichnis) erzeugt wird und eben aus diesem Branch die Datei geöffnet wird.
Ist die Datei fertig bearbeitet und soll veröffentlicht werden, wird ein Merge ausgeführt. SVN schaut dabei also was sich im branch ggü des trunk geändert hat und gibt dem trunk Bescheid, dass bisherige Dateien mit den branch Dateien ersetzt werden sollen. Das ist letztendlich das, was wohl auch die Zusi Verwaltung beim Paketschnüren versucht zu erledigen, nur eben ohne SVN.
Deswegen die Frage: Was war das ursprüngliche Ziel, Carsten, dieses Threads?
Grüße
Max
also ich bin hochgradig verwirrt, muss ich ganz ehrlich sagen.
Ich gebe Markus Recht, dass wir hier aufpassen müssen, entweder mit zu abstrakten Beispielen oder mit nicht transferierten Beispielen zu hantieren.
Ich gebe aber auch Roland Recht, dass SVN die anfallenden Aufgaben eigentlich gut handhaben sollte.
Auf jeden Fall kommen wir nicht darum, um SVN-spezifische, teils englische, Begriffe zu verwenden. Es lebe die gemeinsame Begriffe-Basis! :-)
Was ich im Moment nicht verstehe: Geht es hier um das große, Haupt-Zusi-SVN-Repository auf das auch Bastler zugreifen oder geht es ggf. auch um private SVN-Repositories?
Ein kleiner interdisziplinärer Ausflug:
Angenommen es geht um ersteres, also alle Bastler greifen auf das Haupt-Zusi-SVN-Repository zu. Um es nicht direkt zu kompliziert zu machen: Das besteht aus dem "trunk" in dem die Inhalte gespeichert sind, die auch ausgeliefert werden. Für einen Moment bitte erstmal annehmen, dass es keine unterstützenden Dateien gibt, wie Pläne oder sonst irgendwas, was vielleicht auch im SVN enthalten sein soll. Diese Daten liegen letztendlich auch bei jedem im "_ZusiData" Verzeichnis.
Soll nun ein Teil des bestehenden Zusi-Datenumfangs geändert werden, wird man ja vermutlich die entsprechende Datei öffnen, verändern und wieder abspeichern. Durch die Zusi-Mechanismen landet das dann nicht in diesem ersten ("offizielle Daten") Zusi-Verzeichnis, sondern im zweiten Zusi-Verzeichnis.
Diese Aktion übertragen auf ein SVN würde bedeuten, dass nicht direkt die Datei geöffnet wird, sondern ein Branch der Datei/des Ordners/einer ganzen Unterordnerstruktur/der kompletten Ordnerstruktur aus dem trunk (1. Verzeichnis) in das branch Verzeichnis (2. Verzeichnis) erzeugt wird und eben aus diesem Branch die Datei geöffnet wird.
Ist die Datei fertig bearbeitet und soll veröffentlicht werden, wird ein Merge ausgeführt. SVN schaut dabei also was sich im branch ggü des trunk geändert hat und gibt dem trunk Bescheid, dass bisherige Dateien mit den branch Dateien ersetzt werden sollen. Das ist letztendlich das, was wohl auch die Zusi Verwaltung beim Paketschnüren versucht zu erledigen, nur eben ohne SVN.
Deswegen die Frage: Was war das ursprüngliche Ziel, Carsten, dieses Threads?
Grüße
Max
Administrator, Programmierer, Ansprechpartner bei Problemen mit dem Board
- Michael Springer
- Beiträge: 2930
- Registriert: 24.06.2002 16:22:44
- Wohnort: Schwäbisch Gmünd
Re: SVN sinnvoll nutzen
Sowohl, als auch. Also um beide Varianten.Max Senft hat geschrieben:Was ich im Moment nicht verstehe: Geht es hier um das große, Haupt-Zusi-SVN-Repository auf das auch Bastler zugreifen oder geht es ggf. auch um private SVN-Repositories?
Und genau das geht nicht. Ich formuliere es auch umgangssprachlich jetzt.Ist die Datei fertig bearbeitet und soll veröffentlicht werden, wird ein Merge ausgeführt. SVN schaut dabei also was sich im branch ggü des trunk geändert hat und gibt dem trunk Bescheid, dass bisherige Dateien mit den branch Dateien ersetzt werden sollen.
Im trunk liegen die *.exe Dateien (in Zusi *.ls3 + *.lsb (binäre Geometrien)
Im Branch liegen die *.c Dateien (in Zusi *.ls3 mit XML-Geometrien)
Wie bekomme ich jetzt aus der *.c im Branch eine *.exe im Trunk durch Mergen der Bestände?
Michael
Zuletzt geändert von Michael Springer am 06.04.2020 16:12:32, insgesamt 2-mal geändert.
- MarkusEgger
- Beiträge: 745
- Registriert: 10.11.2001 22:38:17
- Aktuelle Projekte: Augsburg-Donauwörth
- Wohnort: Augsburg
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Hallo Max!
Ich habe kein Problem wenn wir versuchen das Thema mal durchzuspielen, ich möchte einem SVN auch nicht prinzipiell für so einen Zweck negativ gegenüberstehen.
Es ist ja nicht so (und wird es vermutlich auch nie sein), dass alle Bastler auf ein zentrales SVN gesammelt zugreifen und das "Netzzugangskriterium" zum Zusi-Addoneinreichen ist.
Markus
Ich habe kein Problem wenn wir versuchen das Thema mal durchzuspielen, ich möchte einem SVN auch nicht prinzipiell für so einen Zweck negativ gegenüberstehen.
Auf das sogenannte "Große" SVN greifen einige Bastler (überwiegend alte Hasen aus der Vor-Veröffentlichungszeit von Zusi 3) zu, darüber hinaus reden wir auch über weitere SVNs die autark davon leben. Das ist mindestens das des Team Süd, ich weiß nicht wie viele andere es gibt. Und dann reden wir noch über eine Vereinfachung der Einreichung für Bastler, die gar kein SVN nutzen, wie Michael Skupin richtig angemerkt hat. Die haben ja auch das Problem, dass der Einreichungsprozess durch den für die Generierung der zao eigentlich notwendigen dritten Datenbestandes erst mal generiert werden muss. Je kleiner(und autarker von anderen Beständen) ein einzureichendes Addon ist (z.B. nur ein einzelner Führerstand), desto eher ist das bisher handelbar.Was ich im Moment nicht verstehe: Geht es hier um das große, Haupt-Zusi-SVN-Repository auf das auch Bastler zugreifen oder geht es ggf. auch um private SVN-Repositories?
Es ist ja nicht so (und wird es vermutlich auch nie sein), dass alle Bastler auf ein zentrales SVN gesammelt zugreifen und das "Netzzugangskriterium" zum Zusi-Addoneinreichen ist.
Markus
Zuletzt geändert von MarkusEgger am 06.04.2020 15:58:00, insgesamt 2-mal geändert.
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
Re: SVN sinnvoll nutzen
Max, nach meiner Auffassung geht es hier ausschließlich um lokale und freiwillige SVNs, die Einzelkämpfer oder Gruppen für ihre eigene Projekte anlegen.Max Senft hat geschrieben:Was ich im Moment nicht verstehe: Geht es hier um das große, Haupt-Zusi-SVN-Repository auf das auch Bastler zugreifen oder geht es ggf. auch um private SVN-Repositories?
Der im ersten Beitrag von Carsten aufgeführte Hinweis: Zwei parallele Verzeichnisbäume. Das schreit praktisch schon nach Branches.
Nicht mit SVN. Das macht SVN aber auch in der Domäre Softwareentwicklung nicht. Deswegen meine Analogie-Anmerkungen.Michael Springer hat geschrieben:Im trunk liegen die *.exe Dateien (in Zusi *.ls3 + *.lsb (binäre Geometrien)
Im Branch liegen die *.c Dateien (in Zusi *.ls3 mit XML-Geometrien)
Wie bekomme ich jetzt aus der *.c im Branch eine *.exe im Trunk?
Aber wie schon gestern gesagt, bitte nie in den Trunk mergen, der darf nur von Zusi-Update geändert werden. Immer nur in die temporäre Einreich-Branch. Und daraus denn den Change Tree erstellen.