SVN sinnvoll nutzen

Alle Fragen zur Verwaltung, Organisation usw. rund um neue Add-Ons.
Nachricht
Autor
Benutzeravatar
Michael_Poschmann
Beiträge: 19877
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

#21 Beitrag von Michael_Poschmann »

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

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: SVN sinnvoll nutzen

#22 Beitrag von Carsten Hölscher »

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

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#23 Beitrag von Roland Ziegler »

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:
  • 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.
Wenn man sein eigenes SVN, bzw das einer Entwicklergruppe nutzt:
  • 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.
Im Detail kann man die Schritte sicher hier und da variieren, aber das entscheidende ist, dass dieses Bau/Einreich-Szenario sich allein mit SVN-Bordmitteln verwalten lässt - und zudem alle dazu notwendigen Funktionen über die GUI-Oberfläche von TortoiseSVN zur Verfügung stehen.
Zuletzt geändert von Roland Ziegler am 05.04.2020 11:24:25, insgesamt 1-mal geändert.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: SVN sinnvoll nutzen

#24 Beitrag von Carsten Hölscher »

Der Use-Case eigenes Bauprojekt sieht doch so aus, wenn ich das richtig verstehe:
Und das macht man dann für jedes einzelne Objekt? Also jedes Streckenmodul oder jedes Fahrzeug?

Carsten

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#25 Beitrag von Roland Ziegler »

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.

Juergen_Verheien
Beiträge: 3193
Registriert: 07.03.2002 10:09:59
Aktuelle Projekte: Objektbau und Modulgestaltung
Wohnort: Dortmund

Re: SVN sinnvoll nutzen

#26 Beitrag von Juergen_Verheien »

Hallo Carsten,
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
Wie und wo kann man diese Dateien denn festlegen ?
tschüs....

Jürgen

Benutzeravatar
Michael Springer
Beiträge: 2925
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: SVN sinnvoll nutzen

#27 Beitrag von Michael Springer »

Roland schlägt vor
Der offizielle Bestand wandert ins SVN, komplett, als Trunk.
Im offiziellen Bestand gibt es z.B.
- 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

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#28 Beitrag von Roland Ziegler »

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.
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).
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.

Benutzeravatar
Michael Springer
Beiträge: 2925
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: SVN sinnvoll nutzen

#29 Beitrag von Michael Springer »

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
Zuletzt geändert von Michael Springer am 06.04.2020 09:47:10, insgesamt 1-mal geändert.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
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

#30 Beitrag von Michael_Poschmann »

Hallo Namensvetter,

das ist auch der Weg, denn ich gestern - manuell - durchgeführt habe. Von daher meine Unterstützung.

Grüße
Michael

Benutzeravatar
MarkusEgger
Beiträge: 744
Registriert: 10.11.2001 22:38:17
Aktuelle Projekte: Augsburg-Donauwörth
Wohnort: Augsburg
Kontaktdaten:

Re: SVN sinnvoll nutzen

#31 Beitrag von MarkusEgger »

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
Der Blog zum Streckenbauprojekt Augsburg-Donauwörth:
http://www.zusi-team-sued.de

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#32 Beitrag von Roland Ziegler »

MarkusEgger hat geschrieben:Dem SVN Weg traue ich erst wenn einer das wirklich mal für ein Zusi-Projekt durchexerziert hat.
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.

Die üblichen Annäherungsschritte des Nutzers an die Funktionalität eines Repositories sind:
  1. Verteilung
  2. Historisierung
  3. Verzweigung
Die erste Stufe, jeder kommt durch Knopfdruck auf den gleichen Stand, versteht noch jeder. Bei der zweiten, Anwendung der Versionshistorie, wird es schon schwieriger, siehe manche Bemerkung in diesem Thread. Für die dritte, die Arbeit mit Branches, muss man sich sicher noch ein wenig mehr Zeit für die Einarbeitung nehmen. Aber dann wird man vielleicht verblüfft erkennen, dass der hier vorliegende Anwendungsfall sich prima in das Gefüge der Repository-Funktionalität einfügt. Ich war sehr angetan von Max' Beiträgen, die die Branches hier ins Spiel gebracht haben.

Benutzeravatar
MarkusEgger
Beiträge: 744
Registriert: 10.11.2001 22:38:17
Aktuelle Projekte: Augsburg-Donauwörth
Wohnort: Augsburg
Kontaktdaten:

Re: SVN sinnvoll nutzen

#33 Beitrag von MarkusEgger »

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
Der Blog zum Streckenbauprojekt Augsburg-Donauwörth:
http://www.zusi-team-sued.de

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#34 Beitrag von Roland Ziegler »

MarkusEgger hat geschrieben:SVN-Profis ohne Zusi3-Streckenbauerfahrung sagen: Macht das so!
Zusi-Streckenbauer sagen: So klappt das nicht!
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.

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.

Benutzeravatar
MarkusEgger
Beiträge: 744
Registriert: 10.11.2001 22:38:17
Aktuelle Projekte: Augsburg-Donauwörth
Wohnort: Augsburg
Kontaktdaten:

Re: SVN sinnvoll nutzen

#35 Beitrag von MarkusEgger »

Hallo!
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.
Es unterscheidet sich durch noch viel mehr:
- 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

Benutzeravatar
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

#36 Beitrag von Michael Skupin »

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,
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.
ist in meinen Augen sinnvoll und sicherlich machbar. Michael Poschmann hat diesen Gedanken mit positiven feedback bestätigt.
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 :D
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

Benutzeravatar
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

#37 Beitrag von Max Senft »

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
Administrator, Programmierer, Ansprechpartner bei Problemen mit dem Board

Benutzeravatar
Michael Springer
Beiträge: 2925
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: SVN sinnvoll nutzen

#38 Beitrag von Michael Springer »

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?
Sowohl, als auch. Also um beide Varianten.
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.
Und genau das geht nicht. Ich formuliere es auch umgangssprachlich jetzt.

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.

Benutzeravatar
MarkusEgger
Beiträge: 744
Registriert: 10.11.2001 22:38:17
Aktuelle Projekte: Augsburg-Donauwörth
Wohnort: Augsburg
Kontaktdaten:

Re: SVN sinnvoll nutzen

#39 Beitrag von MarkusEgger »

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.
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?
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.
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.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: SVN sinnvoll nutzen

#40 Beitrag von Roland Ziegler »

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?
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.

Der im ersten Beitrag von Carsten aufgeführte Hinweis: Zwei parallele Verzeichnisbäume. Das schreit praktisch schon nach Branches.
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?
Nicht mit SVN. Das macht SVN aber auch in der Domäre Softwareentwicklung nicht. Deswegen meine Analogie-Anmerkungen.

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.

Antworten