Versionsmanagement mit CVS

[Carsten Hölscher]

so ein System hätte sicherlich viele Vorteile. Um es den potentiellen Nutzern näherbringen zu können, wären sicherlich detailliertere Infos nötig, wie genau das in der Praxis abläuft (auch nach dem Gespräch mit Roland wäre mir das für den Anwendungsfall Zusi-Objekte mit vielen Nutzern noch nicht ganz klar).
Vielleicht könnte ja einer der Experten mal so etwas mit allen Bearbeitungsschritten und der einzurichtenden Umgebung skizzieren.

Carsten

[Carsten Luckmann]

Hi,

muß doch mal wieder meinen Senf dazugeben. Wen's stört, der darf den Rest des Artikels übersrpingen.

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 vollbracht hat.

Was sagt das ZPA dazu?

Gerade was das ZPA angeht, hätte aegis gegenüber CVS den Vorteil, daß alles noch einen Review- und Integrationsprozeß durchlaufen muß, bevor es ins Repository kommt. Wenn die ZPA-Prüfer die einzigen sind, die Reviewer- bzw. Integrator-Status haben, ist sichergestellt, daß ohne ihr OK keine Datei ins Repository kommt.

So, und jetzt das Kleingedruckte:
Es braucht Posix, d. h. Checkouts und Commits müßten wohl unter Unix laufen.

Ciao,
Carsten

[Roland Ziegler]

So, und jetzt das Kleingedruckte:
Es braucht Posix, d. h. Checkouts und Commits müßten wohl unter Unix laufen.

Wie würdest Du mit dieser Deiner Aussage dann die Marktchancen beurteilen?

Ich kenne Aegis nicht näher, wundere mich aber mal wieder, dass auch in der Unix-Welt nach wie vor gerne plattformbeschränkt gedacht wird, und würde gleichzeitig nicht allzusehr überrascht sein, wenn ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) als plattformübergreifende systemnahe Middleware auch seteuid() beherrschen würde.

[Carsten Luckmann]

Wie würdest Du mit dieser Deiner Aussage dann die Marktchancen beurteilen?

Hier wohl eher gering. Obwohl es ja nur ums Repository geht. Die Dateien kann man ja weiterhin mit den bekannten Editoren unter Windows bearbeiten.

Ich kenne Aegis nicht näher, wundere mich aber mal wieder, dass auch in der Unix-Welt nach wie vor gerne plattformbeschränkt gedacht wird

Aegis dürfte auf mehr Plattformen laufen als die meisten Windows-Programme. Und in diesem Fall halte ich die suid Lösung für besser als groß verteilte Lese-/Schreib-Rechte, und dafür nimmt man nunmal seteuid. Wenn Du dem Entwickler sagen kannst (oder Code beisteuern kannst), wie man das unter Windows macht, wird er sich wahrscheinlich drum kümmern.

Aber genug des Hickhacks. Das ZPA und Carsten sollten selbst Vor- und Nachteile der einzelnen Systeme abwägen und entscheiden, was ihnen wichtig bzw. machbar ist. Ich wollte lediglich auf ein recht unbekanntes Programm hinweisen, das meines Erachtens sicherer (Datenintegrität) als CVS ist. Und daß es unter Windows nicht läuft, hab ich ja auch dazugeschrieben, damit die Entscheidungsträger gleich wissen, woran sie sind.

Ciao,
Carsten

[rhk]

Hallo,

bitte bleibt bei CVS. Es ist daß am verbreitesten und das System, an dem die meißten Erweiterungen und Support gemacht werden.

Zu dem System würde ich - grob aufgelistet - folgendes empfehlen:

1. Linux-Server mit CVS Server
2. ViewCVS (WebGUI) mit WebDAV Unterstützung

Zum Prozeß würde ich noch vorschlagen, daß es einen öffentlichen Bereich, einen ZPA-Bereich und einen DevEdgebereich gibt.

Durch Scripts werden neue Uploads an das ZPA gegeben und weitergeleitet.

Dies kann man auch via Branches oder besser über Stable- und Sticky-Tags regeln...

Viele Grüße und viel Erfolg,
Robert

[Oliver Lamm]

Ok, nachdem ich meine Klausuren hinter mir habe, hier ein Vorschlag meinerseits:

1. Ich habe hier einen CVS-Server, den ich dem ZPA und Carsten gerne zur Verfügung stelle.

2. Ich habe meine Webseite (zusi.aixnetwork.de) mit dem CMS Typo3 laufen. Es kostet mich somit ein paar Minuten und schon ist ein separater Teil mit Zugangsbeschränkung, sodass dort nur ein ausgewählter Personenkreis zugriff hat (inclusive Upload wenn nötig).

Gruss, Oli

PS: Oberes soll implizieren, das ich dazu bereit bin, die Ressourcen bereitzustellen

[Carsten Hölscher]

mal ne ganz andere Idee zu demselben Thema: Ich bastele gerade die ersten Dateiformate für Zusi 3 zusammen (Diese werden sich zumindest für Fahrzeuge, Führerstände und Verwandte nach gewissen XML-Schema orientieren. Hat ein exaktes Einhalten der XML-Syntax Sinn - wenn ja hat er sich mir noch nicht ganz erschlossen?)
Also zum Thema: Man könnte bei diesem Format die Änderungshistorie in der Datei direkt mit speichern. Wenn also Autor xy einen anderen Leistungswert einträgt, würde das in der Datei vermerkt und der alte Wert archiviert.
Da diese Dateien sowieso klein sind und auch nicht am laufenden Band geändert werden, dürfte der zusätzlich gespeicherte Datenumfang i.d.R. klein und damit nicht das Problem sein.

Carsten

[Roland Ziegler]

Wenn XML, dann richtig XML. Nur dann funktionieren die XML-Klassenbibliotheken. Und deswegen macht man das ganze ja, um sich das Schreiben der Parser zu sparen (für C++ und Java wohl defacto-mäßig mit Xerces). Natürlich muss man sich auch für XML noch eine eigene Syntax überlegen, die auf Zusi-Belange zugeschnitten ist.

Aber Versionsmanagement macht man mit XML üblicherweise nicht. Dafür gibt's doch CVS. Dort wird verwaltet wer wann besagten Wert warum geändert hat ("warum" aber nur, wenn derjenige einen Kommentar hinterlässt).

Diese CVS-Versionsinfo in XML mitzuführen geht natürlich auch, und ist durchaus sinnvoll, dient aber wirklich nur als Info, nicht zur Verwaltung. Dazu gibt's die RCS-Tags, die auch von CVS gepflegt werden. Im XML-File baut man einen entsprechenden Kommentar mit dem Tag $Log$ ein und schon führt CVS wunderbar die ganze Historie im File mit. Das wäre also dann kein XML-Syntax-Bestand, sondern schlicht Kommentar. Wenn man möchte, könnte man aber auch ein XML-Tag aufsetzen, was dann mit dem Wert eines CVS/RCS-Tags besetzt wird.

Hier mal ein Beispiel, wie das im Code als Kommentar aussieht, Beispiel für C++:

Code: Alles auswählen

 * Revision 1.22  2002-08-26 13:31:01+02  zi
 * Outlevel für einige Standardmeldungen eingeführt
 *
 * Revision 1.21  2002-06-25 17:39:51+02  zi
 * Merged from branch 'Custom Marshaling Incorporation Test '.
 *
 * Revision 1.20.2.3  2002-06-24 15:41:39+02  zi
 * Specific Converter in receiving direction,
 * "any" discarded for CFrameSeq
 *
 * Revision 1.20.2.2  2002-06-10 09:46:22+02  zi
 * Anpassungen Test Custom Marshaling
 *
 * Revision 1.20.2.1  2002-06-04 09:28:27+02  zi
 * kompilierfähig

[Gast]

Als XML-Halb- bis Viertelwissender darf ich ein Statement zitieren, aufgeschnappt in dieser Woche während einer Sitzung.

Frage: Warum soll hier csv-Format verwendet werden anstelle von XML-Notation?
Antwort: Datenmenge! Bei csv sind die Separatoren schön knapp, in XML werden die Kommata beliebig breit...

Michael

[Roland Ziegler]

Auch mir hat sich der Hype um XML bisher nicht vollständig erschlossen. Es ist halt ein praktisches Format, um allen möglichen Objekt-Sinn- und -Unsinn auf einfache Weise zu serialisieren/deserialisieren, dank ausgeklügelter Klassenbibliotheken. Und das spart reale Entwicklungszeit. Für Massendaten ist es IMHO denkbar ungeeignet, solange man nicht für die Festplattenindustrie arbeitet. Der von Open Office beschrittene Weg der anschließenden Komprimierung scheint mir eher ein Notbehelf statt eleganter Architektur zu sein.

Doch für die typischen kleinen Zusi-Datenfiles diverser Aufgabenbereiche wüsste ich nicht, was dagegen sprechen sollte. Hier erscheint es mir als das ideale Format.

Mit csv-Feldtrennern hat sich Carsten bisher nicht abgegeben, da kommt doch immer gleich ein Line Feed . Aber auch die brauchen in XML schon einiges an Breite .

[Carsten Hölscher]

also die dreißigzeilige Parserklasse war ja schneller programmiert als das Suchen und Runterladen der offiziellen Vorgaben....
Frage in die Runde: Besteht seitens dritter Interesse, dass da XML eingehalten wird? Im Moment sieht es syntaktisch eher aus wie ein x-File. Ist aber im Prinzip kein Problem das zu ändern.

Carsten

[Daniel Schuhmann]

In dem Zusammenhang möchte ich nochmal auf die XML Parser-Klasse für Delphi hinweisen, die ich selbst gerne benutze. Superschnell, kostenlos und mit sehr guter Hilfe.

http://www.destructor.de/xmlparser/

Beim letzten Vorschlag zu diesem Format wurde ich (warum auch immer) durch ein mehrere KB großes Word-XML (was mit XML nicht mehr viel zu tun hat) erschlagen...

[F(R)S-Bauer]

...
Beim letzten Vorschlag zu diesem Format wurde ich (warum auch immer) durch ein mehrere KB großes Word-XML (was mit XML nicht mehr viel zu tun hat) erschlagen...

Man(n) versucht ja dazu zu Lernen, und ziehe hiermit den Schlag mit Bedauern zurück.

[Roland Ziegler]

Es gibt zu XML die veschiedensten Betrachtungen. Das reicht halt von völliger Verklärung und dem Versprechen einer schönen neuen IT-Welt, die nicht nur Objektserialisierung löst, sondern auch noch fast alle anderen irdischen Probleme, und reduziert sich andererseits auf ein ganz simples, aber ausgewalztes Datenformat, das nur wahnsinnig Overhead produziert.

Das XML ersteres nicht erfüllt, wird einem wohl schnell klar, wenn das übliche Marketing-Geschwafel erklingt, und bei normal denkenden Menschen erstmal gesteigerte Skepsis auslöst.

Die Wahrheit liegt wie meist in der Mitte.

XML ist nämlich andererseits doch deutlich mehr als das simple Datenformat, als das es auf den ersten Blick erscheinen mag, weswegen von selbst geschriebenen Parsern, die auch nur einen Bruchteil der Möglichkeiten abdecken sollen, nur abgeraten werden kann.

Für Zusi bietet sich als API SAX an. SAX ist das Event-Driven-Modell, während DOM das Tree-Modell ist. Wobei ich keine Ahnung habe, ob es eine ordentliche SAX-Portierung für Delphi gibt. (Das bleibt halt unter den Softwarearchitekturen eine recht exotische Umgebung, ungeachtet der großen Community. Die OO-Theoretiker forschen nun mal für C++ und Java). Hier ist zumindest ein Link: http://xml.defined.net/sax/

Für OO-Entwickler, die auch bisher schon kräftig mit Containern und Factories gearbeitet haben, ist SAX praktisch out-of-the-box benutzbar.

Deswegen natürlich auch der Wunsch, Standard-XML einzusetzen.

[Michael_Poschmann]

Hallo Roland,

-nunmehr wieder eingelogged-

die Landschaftsdatei würde ich aber durchaus zu den Massendaten zählen. Bei den Fahrzeugen und Signalen ließe sich natürlich darüber diskutieren, wieviele Stellen ein Komma haben soll...

Michael

[Roland Ziegler]

Im Büro haben wir jetzt gerade so ein Ding mit 30 MB, noch mit fast jedem Text-Editor zu öffnen, wirklich übersichtlich und voller Netto-Informationen .

[Carsten Hölscher]

mal unabhängig von meiner Implemetierung (dazu werde ich mich mit Dir noch kurzschließen Roland) nochmals die Frage an potentielle Zusatzsoftware-Entwickler so für mich als Hintergrundinfo: Wäre es für Euch hilfreich, wenn Zusi sauberes xml ausgibt?

Carsten

[Daniel Rüscher aka Merlin]

Hui Carsten, ich gratuliere zu deinem 2222ten Beitrag...