Versionsmanagement mit CVS

Alles zu Zusi-Performance, Frameraten, ruckelnden Bildern, Grafik, Treibern usw.
Nachricht
Autor
Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Versionsmanagement mit CVS

#1 Beitrag von Roland Ziegler »

Im alten Forum hatten wir das Thema schon mal:

Versions- und Quellcodeverwaltung, nicht nur für Softwareentwickler, sondern auch für Strecken-, Landschafts,- 3D-Modell-, und Führerstandsbauer.

Das bekannteste Verwaltungssystem dafür ist CVS (Concurrent Versions System), ein Open Source Projekt, ursprünglich zu Hause in der Unix-Welt.

Dass es auch für Zusi-Zwecke geeignet ist, hat Oliver Lamm schon vor langer Zeit mal demonstriert, z.B. in jenem Thread im alten Forum. (@Oli: Wo ist das entsprechende Tutorial auf Deiner Webpage geblieben?)

Für die Heimarbeit im Zusi-Bereich habe ich CVS bisher nicht benutzt, weil es bis vor Kurzem kein gescheites Plugin für Visual Studio gab. Das hat sich jetzt aber geändert. Damit steht nach vielen Jahren, in denen sich nichts tat, nun endlich auch für das Microsoft IDE ein gescheiter und trotz aller Mächtigkeit des CVS einfacher Zugang zur Verfügung. Selbst für Borland gibt es eine Integrationsmöglichkeit, die kostet jedoch - als einziges Produkt - einen Obolus.

Ich selbst stelle jetzt zu Hause um, von Visual Source Safe auf CVS, weil ich es leid bin, mich mit dem unmöglichen Verwaltungsmodell von VSS auseinanderzusetzen, wenn man sowas einfaches machen will, wie eine Branch anlegen und verfolgen. Die Notwendigkeit war jetzt grad wieder gekommen, als eine Spezialversion des 3D-Viewers gebraucht wurde. Da müssen dann zwei Varianten parallel gepflegt werden, mit VSS ein Horrortrip.

Zurück zu CVS: Wo gibt's was? Hier diverse Links, und wofür was jeweils gut ist:
  • CVS-Original: Für Unixer. Für Windowser ist hier nur das Handbuch von Per Cederqvist (et al) von Interesse, die CVS-"Bibel":
    http://www.cvshome.org/docs/manual/
  • CVS für Windows NT (und natürlich 2000, XP und 2003 Server); sorry, nicht für Home-Windows.
    http://www.cvsnt.org/wiki/
    Wir brauchen das aktuelle Release-Paket und sollten uns außerdem die "Installation-Tips" aus der Doc-Ecke kopieren.
  • WinCVS, das "normale" GUI für CVS unter Windows. Oder will jemand ernsthaft Shell-Kommandos einhacken?
    Ich würde den Link über die Homepage nehmen, man landet dann eh bei SourceForge.
    Die Software (1.3.x beta) http://www.wincvs.org/download.html
    Doku für 1.3 als pdf: http://www.wincvs.org/doc.html
  • Die Shell von WinCVS benutzt Python und Tcl. Beides in einem bekommt man bei
    http://www.python.org/
  • Visual Studio - Plugin. Das braucht man für die tägliche mausklickarme Nutzung unter Visual Studio, Version 5(?), 6 oder 7.x, und vermutlich auch für Visual Basic bis Version 6 einschl, ab 7.0 ist VB ja integriert.
    http://pushok.com/soft_cvs.php
    Dieses Plugin names "CVS-Proxy" bildet das SCCI-Interface von MS auf CVS ab, und ist ganz frisch auf dem Markt, daher noch weitgehend unbekannt. Man braucht nur den Download.
    Der Schöpfer, Igor Puschkow, verrät auf seiner Website leider nur sehr wenig über sich selbst.
    Achtung: Das Plugin muss registriert werden, derzeit umsonst.
  • Und schließlich die Anbindung an Borland. Hier bietet die Firma Devrace ein Modul namens Athland, was wiederum das Borland'sche IDE (Delphi, C++-Builder) an SCCI koppelt. Das Teil kostet Geld - als einziges in der ganzen Kette, derzeit €63,95 als "Athland Personal". Wenn man Athland einsetzt, wird ebenfalls das CVS-Proxy benötigt.
    http://www.devrace.com/athlant/
Der Einstieg in Source-Control ist - als Vorwarnung - nicht ganz trivial. Mit dem Lesen der diversen Manuals kommt man aber recht schnell zu einem funktionierenden System.

Übrigens verwende ich nicht, wie von Oli damals angesprochen, ssh als Zugang zum Repository, wegen zu kompliziert, sondern entweder das pserver-Protokoll, wenn mein Repository auf Unix liegt, oder das neue sspi-Prokokoll, wenn's auf NT ist. Wenn man ausschließlich lokal arbeitet, kann man auch "local" benutzen, ich würd's aber nicht empfehlen.
Zuletzt geändert von Roland Ziegler am 16.07.2003 23:20:49, insgesamt 1-mal geändert.

Benutzeravatar
Oliver Lamm
Beiträge: 3102
Registriert: 04.01.2002 15:02:17
Aktuelle Projekte: Aachen - Neuss für Zusi3
Wohnort: Essen
Kontaktdaten:

#2 Beitrag von Oliver Lamm »

(@Oli: Wo ist das entsprechende Tutorial auf Deiner Webpage geblieben?)
Im zuge der Umstrukturierung auf der Strecke geblieben ?
Werde es wieder ausgraben und online stellen.

Vielleicht noch am Rande erwähnt:

http://www.tortoisecvs.org/

Mit diesem Plugin für den Explorer habe ich immer gearbeitet.

Gruss, Oli
Oliver Lamm
mail(AT)oliverlamm(DOT)de

rhk
Beiträge: 72
Registriert: 14.05.2003 13:22:14

#3 Beitrag von rhk »

Die Idee mit dem CVS ist sehr gut. Schließlich gibt es auch ein freies Web-Gui für das CVS.

Leider habe ich bislang folgende - teilweise unangenehme - Erfahrungen damit gesammelt. Die unangenehmen Erfahrungen resultieren jedoch daraus, daß CVS nicht ordentlich konfiguriert wurde.

Das von Roland preferierte CVS für NT kann einiges nicht, was das Linux/Unix-CVS kann. Vieles was dort reibungslos funktioniert, klappt bei CVS for NT nur mit einigem Umstand.

Beispiel:
- Notification. Dafür muß bei einem NT/W2K-System eine eigene "Mail"-Adaption erfolgen,
- LDAP-Synchronisation. Gerade das WebCVSGui braucht eine Möglichkeit, die .htaccess mit dem CVS-System zuz synchronisieren. Was bei Linux ganz gut klappt, scheitert oft an der Administration des CVS for NT Systems.

Ein großes Problem bei CVS sind .EXE- oder .ZIP-(+derivate) Dateien, die ewigkeiten zum ein/auschecken brauchen. Hinzu kommen Probleme mit Whitespaces, die mir schon manche Merge-Nacht eingebrockt haben.

Zusätzlich sehe ich in CVS auch ein Risiko; wenn Anwender sich nicht auskennen, ist das gesamte Repository durch wahllose Locks, irgendwelche konstrusen Watches oder ähnlichem lahmgelegt.

Wir haben hier in der Firma für unsere Abteilung ein relativ ausgeglichenes Repository mit CVSforNT angelegt und festgelegt, daß keine Edit-Locks und keine Watches gesetzt werden. Jedoch gibt es auch eine andere Abteilung, die ein Lokales Repository auf einem Fileserver (hilfe wie sind die nur darauf gekommen) angelegt haben und nun immense Probleme durch irgendwelche Perl-Scripts versuchen wegzubekommen. Dann checken die auch NICHTfunktionierende Sourcen ein, was bei uns "verboten" ist.

Branches handelt CVS eigentlich ganz gut. Wenn man mit den Kommando-Zeilen-Optionen nicht klarkommt, ist das freie WinCVS die beste Alternative. Vorallem die graphische Darstellung und der automatische Conflict-Resolve ist hier zu erwähnen.

Allerdings fehlt dem WinCVS ein geeignetes Diff/Merge-Tool. Dafür verwenden wir das perfekte Diff/Merge von eclipse.

Alles in allem funktioniert ein CVS-Repository NUR, wenn man sich an ganz bestimmte Regeln hält und jemand sich verantwortlich zeichnet, der das Repository administriert (vorsicht: teilweise sch...job).

Aber wenn Ihr Euch entschließt, so etwas zu bauen, dann bin ich dabei und unterstütze Euch auch gerne dabei. Jedoch macht das in unserem Fall (ich denke da an Add-Ons) nur Sinn, wenn es ein WebGui gibt.

Ich könnte mir z.B. vorstellen, daß es für verschiedene Führerstände die Branches gibt, daß Strecken mit Branch für Version 2.3 oder 2.4 existieren etc.

OpenSource möchte ich mich nicht anschließen. Allenfalls an eine offengelegte (und die dann als OpenSource betrachtet) Schnittstelle wie hier schon in einigen Threads debattiert.

Viele Grüße,
Robert

Carsten Luckmann
Beiträge: 172
Registriert: 05.11.2001 13:49:34
Aktuelle Projekte: Seelze
Wohnort: APB
Kontaktdaten:

#4 Beitrag von Carsten Luckmann »

Hallo,

wo wir gerade bei den Schwächen von CVS sind: Sobald das Repository mehrere Dateien enthält und mehr als ein Entwickler Zugriff darauf hat, ist es möglich, daß das Repository irgendwann in einen inkonsistenten Zustand gerät, der nur durch Eingriff eines (verantwortungsbewußten) Entwicklers behoben werden kann. Folgendes Szenario:

Entwickler A checkt DateiY aus und ändert sie.
Entwickler B checkt DateiX und DateiY aus und ändert beide.
Entwickler A checkt DateiY wieder ein.
Entwickler B checkt seine Änderungen ein.

Dabei wird DateiX akzeptiert, DateiY anschließend wird dagegen zurückgewiesen, da sie zwischenzeitlich geändert wurde. Fertig ist der Datensalat. Bleit nur noch zu hoffen, daß Entwickler B DateiY sofort anpaßt, damit das Repository möglichst schnell wieder in einen konsistenten Zustand kommt, und daß inzwischen niemand die inkonsistenten Daten verwenden will.

Nebenbei sollte natürlich die Verwendung des pservers verboten werden, da unverschlüsselt.

Ciao,
Carsten

rhk
Beiträge: 72
Registriert: 14.05.2003 13:22:14

#5 Beitrag von rhk »

@carsten:

1. cvs update DateiY
sollte C (=Conflict) bringen

also
2. cvs diff -b -r [letzte Revisionsnummer] DateiY
nun manueller Merge der Änderungen und im folgenden:

3. cvs commit -f -r [neue Revisionsnummer] DateiY

Dabei sollte [neue Revisionsnummer] genau um .1 erhöht als [letzte Revisionsnummer] der DateiY im Repository

Das ist eben der Umstand... und deshalb plädiere ich für feste Regeln im Umgang mit dem CVS Repository.

Also sowas wie:
1. Auschecken
2. Lock oder Edit setzen
3. Ändern
4. Einchecken
5. Lock oder Edit entfernen.

Dann kann EntwicklerB die Datei nicht auschecken, solange EntwicklerA den Edit gesetzt hat. EntwicklerB kann ja in der Zwischenzeit den Watch auf DateiY setzen...

Aber wie gesagt, CVS MUSS ordentlich betrieben werden und jeder Entwickler (der auch committen darf) muß sich seiner Verantwortung bewußt sein.

Robert

PS: Die CVS-Integrationen in Eclipse oder Netbeans gehen deshalb auch immer so vor, daß sie erst updaten(incomming) und dann commiten(outgoing)...
Zuletzt geändert von rhk am 17.07.2003 14:38:33, insgesamt 1-mal geändert.

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

#6 Beitrag von Andreas Karg »

Wär's dann nicht sinnvoll, softwareseitig festzulegen, dass eine Datei zu einem beliebigen Zeitpunkt nur maximal einmal ausgecheckt sein darf? Oder geht sowas nicht?

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

#7 Beitrag von Roland Ziegler »

Oliver Lamm hat geschrieben:Vielleicht noch am Rande erwähnt:

http://www.tortoisecvs.org/
Die Schildkröte hatte ich vergessen. Manche Leute mögen zwar keine Explorer-Extensions, weil sie sagen, das macht den Explorer langsam. Andererseits ist die Benutzung dieses Frontends m.E. aber sogar intuitiver als WinCVS. WinCVS ist immer noch mehr eine Kapselung von Shell-Kommandos. Drum ja auch meine Favorisierung eines Visual Studio Plugins (wobei ich zu dem von Tortoise keine Zuneigung entwickeln konnte.)
rhk hat geschrieben:Leider habe ich bislang folgende - teilweise unangenehme - Erfahrungen damit gesammelt.
CVS ist alles andere als perfekt. Mit den Haken und Ösen kann man sich aber arrangieren. Mich stört auch die Unix/Open-Source-typische Vielfalt an Tools für alles un jedes. Das ist recht gewöhnungsbedürftig. Vielleicht wird ja mal Subversion in die Fußstapfen von CVS treten.

rhk hat geschrieben:Alles in allem funktioniert ein CVS-Repository NUR, wenn man sich an ganz bestimmte Regeln hält und jemand sich verantwortlich zeichnet, der das Repository administriert (vorsicht: teilweise sch...job).
Ich würde es sehr begrüßen, wenn auf irgendweinem Server ein Zusi-Repository angelegt würde. Müssten wir nur noch einen Admin finden.

@Oli: Wolltest Du Dich nicht mal breitschlagen lassen?

In jüngster Zeit hat es mal wieder eine größere Umbauorgie bei den Add-Ons gegeben (für die anstehende Zusi 2.4). Mit einem zentralen Repository könnte man sicher manchen Wildwuchs eindämmen, was auch Erlbach/Vogtl. freuen könnte. Das Repo muss ja nicht frei zugänglich sein, auch nicht für nur Read-Only.
Carsten Luckmann hat geschrieben:Sobald das Repository mehrere Dateien enthält und mehr als ein Entwickler Zugriff darauf hat, ist es möglich, daß das Repository irgendwann in einen inkonsistenten Zustand gerät, der nur durch Eingriff eines (verantwortungsbewußten) Entwicklers behoben werden kann.
Ich habe das Gefühl, dass die mit CVS (=Concurrent) verbundene prinzipielle Arbeitsweise in der Praxis sehr viel weniger Ärger bereitet als man zu Beginn meint. Es ist doch auch nichts anderes als das Auflösen von Konflikten beim Merge von Branches in Exclusive-Lock Systemen.
Carsten Luckmann hat geschrieben:Nebenbei sollte natürlich die Verwendung des pservers verboten werden, da unverschlüsselt.
Das kommt doch aber sehr drauf an. Nicht für jede Anwendung muss man mit Kanonen auf Spatzen schießen. pserver ist einfach und harmlos.
AndiK hat geschrieben:Wär's dann nicht sinnvoll, softwareseitig festzulegen, dass eine Datei zu einem beliebigen Zeitpunkt nur maximal einmal ausgecheckt sein darf? Oder geht sowas nicht?
Das hat man bei älteren Systemen gemacht, wo dann immer eiener rumrennen musste, und die Leute anhalten, ihren Kram doch entweder bitte einzuschecken, oder das Lock aufzuheben. Bei CVS geht es theoretisch auch exklusiv, aber bei uns wird es so nicht benutzt - und wohl in vielen anderen (kleineren) Umgebungen auch nicht.

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

#8 Beitrag von Andreas Karg »

Hmm...Oder dann vielleicht wenigstens ne entsprechende Markierung der Datei, sodass etwaige Bastler sehen "Aha, da is grad einer am Basteln, die Datei könnt demnächst veraltet sein" oder so...

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

#9 Beitrag von Roland Ziegler »

Aber klar, das kann CVS :D

Carsten Luckmann
Beiträge: 172
Registriert: 05.11.2001 13:49:34
Aktuelle Projekte: Seelze
Wohnort: APB
Kontaktdaten:

#10 Beitrag von Carsten Luckmann »

Hallo,

das Problem ist eigentlich nicht, daß mehrere Entwickler gleichzeitig an ein und derselben Datei arbeiten können, sondern die Tatsache, daß CVS partielle Commits erlaubt, also vor Akzeptieren der ersten Datei nicht überprüft, ob es überhaupt alle annehmen kann.

Was die Locks angeht: Entwickler A checkt eine Datei aus, sperrt sie für andere Nutzer und fängt an, daran zu arbeiten. Dann wird er plötzlich krank, und keiner hat mehr Zugriff auf die Datei. Ok, ein Admin kann den Lock entfernen, aber was ist dann mit den Änderungen, die schon vorgenommen wurden? Womit wir wieder bei der Gefahr eines partiellen Commits wären ...

Je größer die Anzahl der Dateien und Entwickler ist, desto größer wird auch die Wahrscheinlichkeit eines solchen partiellen Commits, egal welchen Verhaltenskodex man sich für die Entwickler ausgedacht hat). Daher sollte man sich ab einer bestimmten Projektgröße gegen CVS entscheiden und stattdessen andere Systeme wie z.B. Aegis (gibt's allerdings nur für POSIX-Systeme), oder Subversion.

Ciao,
Carsten

Benutzeravatar
Oliver Lamm
Beiträge: 3102
Registriert: 04.01.2002 15:02:17
Aktuelle Projekte: Aachen - Neuss für Zusi3
Wohnort: Essen
Kontaktdaten:

#11 Beitrag von Oliver Lamm »

Ich würde es sehr begrüßen, wenn auf irgendweinem Server ein Zusi-Repository angelegt würde. Müssten wir nur noch einen Admin finden.

@Oli: Wolltest Du Dich nicht mal breitschlagen lassen?
Prinzipiell kein Problem. Ich habe einen CVS-Server laufen, muss nur mal schauen, wie ich das am geschicktesten mit der Authentifizierung hinbekomme. Wahrscheinlich mittels pserver :(
Ich denke wir sollten mal genau untersuchen, für welche Bereiche es wirklich interessant ist. Ich kann/will schliesslich nicht für aberhunderte von Entwicklern hier das Hosting machen. Dazu habe ich a) nicht die Zeit, b) nicht die Kapazität, c) will ich Sourceforge und Co keine Konkurrenz machen :)

Ich habe meine Anleitung grad mal wieder so auf die schnell zusammengeflickt, sie ist auf meiner Seite online.
Oliver Lamm
mail(AT)oliverlamm(DOT)de

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

#12 Beitrag von Roland Ziegler »

Prinzipiell kein Problem. Ich habe einen CVS-Server laufen, muss nur mal schauen, wie ich das am geschicktesten mit der Authentifizierung hinbekomme. Wahrscheinlich mittels pserver
Warum denn nicht? Welche böswilligen Zusigegner hören denn die Leitungen ab? :rolleyes:
Ich habe meine Anleitung grad mal wieder so auf die schnell zusammengeflickt, sie ist auf meiner Seite online.
Prima. Die Bilder sind nur jetzt etwas sehr klein :O. Und wenn man wg pserver den ssh-Teil auch noch überlesen kann :) , wird es doch recht einfach, oder? :mua

rhk
Beiträge: 72
Registriert: 14.05.2003 13:22:14

#13 Beitrag von rhk »

AndiK hat geschrieben:Hmm...Oder dann vielleicht wenigstens ne entsprechende Markierung der Datei, sodass etwaige Bastler sehen "Aha, da is grad einer am Basteln, die Datei könnt demnächst veraltet sein" oder so...
Das geht mit:

cvs edit -a all [Dateiname]

Viele Grüße aus Grafing nach Grafing,
Robert

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

#14 Beitrag von Andreas Karg »

Oh, es gibt tatsächlich NOCH einen Grafinger unter den Zusianern? (DAS Grafing am Ende der Welt (aka S5)?

rhk
Beiträge: 72
Registriert: 14.05.2003 13:22:14

#15 Beitrag von rhk »

Roland Ziegler hat geschrieben:
AndiK hat geschrieben:"]Wär's dann nicht sinnvoll, softwareseitig festzulegen, dass eine Datei zu einem beliebigen Zeitpunkt nur maximal einmal ausgecheckt sein darf? Oder geht sowas nicht?
Das hat man bei älteren Systemen gemacht, wo dann immer eiener rumrennen musste, und die Leute anhalten, ihren Kram doch entweder bitte einzuschecken, oder das Lock aufzuheben. Bei CVS geht es theoretisch auch exklusiv, aber bei uns wird es so nicht benutzt - und wohl in vielen anderen (kleineren) Umgebungen auch nicht.
... wäre eben die Frage, WAS man lockt - also entweder man lockt die Datei nur für COMMITS und nur für andere Benutzer oder man lockt ALLES.

Bei PVCS wird der Lock automatisch nach dem Commit freigegeben. Zusätzlich wird der Benutzer beim Beenden des Editierens der Datei gefragt, ob er committen will oder nicht. Einige Entwicklungsumgebungen machen das auch für CVS...

Robert

@ANDI: JAWOLL... zugroaster... (Poststraße)
Zuletzt geändert von rhk am 17.07.2003 17:24:04, insgesamt 1-mal geändert.

Benutzeravatar
Oliver Lamm
Beiträge: 3102
Registriert: 04.01.2002 15:02:17
Aktuelle Projekte: Aachen - Neuss für Zusi3
Wohnort: Essen
Kontaktdaten:

#16 Beitrag von Oliver Lamm »

Die Bilder sind nur jetzt etwas sehr klein
Mussu tun klicken auf dat Foddo ...

Oli
Oliver Lamm
mail(AT)oliverlamm(DOT)de

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

#17 Beitrag von Andreas Karg »

Meine Güte, dann hockst du ja maximal 800m von mir weg... Nie gedacht, dass ich SOWAS noch erleben darf! *g*

Andi (vom Grenzspitz, Ecke Bernauer Straße - Hesselfurter Weg, droben kurz vorm Lentner)

rhk
Beiträge: 72
Registriert: 14.05.2003 13:22:14

#18 Beitrag von rhk »

... übrigens, (wer's noch nicht kennt)

Ein sehr gutes Buch hat Herr Karl Fogel (kein Schreibfehler) geschrieben:
OpenSource-Projekte mit CVS

ISBN:382660816X

Dort gibt es auch ein Kapitel über Konfliktvermeidung und -auflösung...

Robert

PS: @andi: dafür höre ich jeden morgen und abend die S-Bahnen von der 30km/h-Kurve vor Grafing-Stadt quietschen :P
Zuletzt geändert von rhk am 17.07.2003 17:31:30, insgesamt 1-mal geändert.

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

#19 Beitrag von Andreas Karg »

Dafür darfste dich bei'm Fahrer von so nem Volksfest-Attraktionen-Bumsdings-Laster bedanken. Der hat es geschafft und is mit dem Ding aufm BÜ stehengeblieben, weil vor ihm mal wieder Stau war (Entsprechende Schilder beachtet man ja nicht) und dann sind die Schranken runtergekommen. Seitdem haben wir da eine La, die aber erst vor ~1 Jahr in eine Dauer-La umgewandelt wurde...

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

#20 Beitrag von Roland Ziegler »

Ein sehr konkreter Vorschlag meinerseits:

Aufnahme des Zusi-Fahrzeugparks in CVS.

Für die kommenden Monate wird in diesem Segment eine schrittweise Weiterentwicklung zu den Möglichkeiten von Zusi 2.4 (Nacht-Version der Fst, Entfall der Blindfenster), und dann anschließend in Richtung Zusi 3 (Texturen, Animation etc) erfolgen.

Typische Aufgaben für Release-Version-Tagging, Trunk- und Branch-Entwicklung.

Auch für die leidigen technischen Daten des Fahrzeugs gibt es nur noch eine definierte gültige Variante, und die Sache mit dem "Das hatten wir doch schon mal korrigiert, da muss von plötzlich eine alte Version wieder nach oben geschwemmt worden sein" lässt sich nachverfolgen und ggf rückgängig machen.

Die Directory-Struktur wird eh vom ZPA vorgegeben, und der Entwickler bekommt sie beim Auschecken automatisch aufgepresst. (CVS hat den bekannten Nachteil, dass es keine wirkliche Strategie für Umbennung/Verschiebung von Files & Directories gibt, mit dem Vorhandenen kann man für Zusi-Zwecke aber wohl gut leben, und muss nicht auf Subversion warten.)

Natürlich kann man auch den Bestand an Strecken einbeziehen (2. Schritt?). Hier sind insbesondere konsistente Streckendateien ("Signal-, Fahrstraßen- und Ereignis-Schaltpläne") sowie natürlich Fahrpläne von Interesse.

Ich stelle mir das Ganze natürlich nicht mir offenem, anonymen Portal vor, sondern mit konkreten, autorisierten Benutzern, wo man hinterher schon feststellen kann, wer wo wann welche (Fehl :§$% )-Leistung :wow vollbracht hat.

Was sagt das ZPA dazu? :ausheck

Antworten