CVS

[Roland Ziegler]

Um diesen Thread wieder aufzuwärmen:

Olis Vortrag in Braunschweig zu CVS hatte ja regen Anklang gefunden, und möglicherweise hat der eine oder andere Zusianer seinen Streckenbau in der Zwischenzeit bereits umgestellt.

Ich hab mir nun mal Subversion (SVN) näher angeguckt, den potentiellen irgendwann-mal Nachfolger von CVS.

Gerade für ZPA-Tätigkeit hätte SVN durchaus Vorteile, durch versionierte Directories. Und auch die Bitmaps würden effizeinter verwaltet als unter CVS. Soweit, so gut.

In der Praxis gibt es jedoch noch diverse Hürden.

Das Aufsetzen eines Servers würde ein Thema für sich darstellen. Zwischen den beiden Extremen: Apache Web Server und File-Direktzugriff für Standalone gibt es noch SVNServe. Dort scheint durchaus Potential vorhanden zu sein. Was fehlt, ist für Windows die Verpackung als Service. Dass es mit srvany geht, wissen vermutlich nur recht wenige Anwender, die Doku verweist nicht darauf, und in der TortoiseSVN-Doku wird man an Stelle des kostenlosen srvany an ein kommerzielles Produkt verwiesen.

Dann das Repository selbst. Momentan (vor SVN 1.1) muss es als Datenbank angelegt werden, was mit einigem an zusätzlicher Admin-Arbeit für ein automatisiertes Backup verbunden ist. Wird sich ab 1.1 aber wohl ändern.

Mit dem TortoiseSVN-Client steht auch schon eine halbwegs nutzbare Umgebung für den Explorer zur Verfügung.

Für alltäglichen einfachen Gebrauch, also Update-Modify-Commit, ist SVN in Zusammenarbeit mit TortoiseSVN schon ganz gut nutzbar.

Die Probleme aber beginnen beim Branching/Tagging/Merging. Dies stellt sich für CVS-Nutzer als böse Falle heraus (und erinnert an Microsofts unseliges VSS). SVN kennt nämlich keine Branches und Tags, sondern nur "Kopien" von Directory-Bäumen. Ein durchaus logisches Konzept, und sehr flexibel. So flexibel, dass man sofort die Übersicht verliert.

Branching und Tagging sind bei CVS Eigenschaften der verwendeten RCS- Filestruktur. Der Anwender nutzt diese Eigenschaften, ohne sich weiter Gedanken machen zu müssen. In SVN aber muss man derzeit als erstes eine Menge Planungen anstellen, wie man denn sein Repository aufbauen möchte, um darin später noch Branches und Tags identifizieren zu können, denn SVN kennt so etwas von Hause aus eben nicht. Eine Branch oder ein Tag ist lediglich eine Frage der Interpretation eines Directory-Trees mit Vorfahren.

Das Anlegen einer Branch erfordert zunächst die Überlegung, wo man denn seine Branch ansiedeln möchte. Dann muss man den Pfad bis zum neuen Root-Directory anlegen, und dann kann man kopieren. Der CVS-Nutzer hat inzwischen seine Kaffepause bereits beendet.

Möchte man nun Änderungen zwischen Trunk und Branch hin- und herkopieren, oder die Branch zum Schluss wieder in den Trunk mergen, dann ist man erst richtig verlassen. Man darf nämlich zunächst selbst herausfinden, wo und wann denn die Verzweigung stattfand. Dies erfordert vom Nutzer größte Disziplin bei der Vergabe von Log-Messages, in die man selber eintragen darf, was in RCS/CVS vollautomatisch abläuft. Wenn man dann die Verzweigungststelle gefunden hat, darf man deren Revisonsnummer eintragen, um damit den Merge zu beginnen. Auch hier hat der CVS-Nutzer bereits seine (2.) Kaffeepause hinter sich, bevor man mit SVN ein Ergebnis erzielt hat.

Den SVN-Erfindern ist die Problematik wohl durchaus bewusst, sie schreiben viele schlaue Hinweise in die Doku, aber erklären nicht, warum sie es für den SVN-Anwender so kompliziert und fehlerträchtig machen.

Manches ließe sich vermutlich schon auf Client-Seite lösen, und vielleicht geschieht das auch irgendwann. Aber derzeit muss ich der Kritik zustimmen, dass der Umgang mit Branches sehr schnell zum Alptraum werden wird.

[Frank Wenzel]

Um diesen Thread wieder aufzuwärmen:

Olis Vortrag in Braunschweig zu CVS hatte ja regen Anklang gefunden, und möglicherweise hat der eine oder andere Zusianer seinen Streckenbau in der Zwischenzeit bereits umgestellt.

Ich hab mir nun mal Subversion (SVN) näher angeguckt, den potentiellen irgendwann-mal Nachfolger von CVS.

...

So schnell schießen die Preußen hoffentlich nicht, wenn man deinen Bericht so liest.

Ich habe für meinen Teil der KBS650 begonnen, mit dem von Oli in HBS vorgestellten CVS zu arbeiten und bin schlichtweg begeistert! :respect Vor allem die aufgrund des Versionsmanagements mit CVS recht übersichtlich gebliebenen Ordner innerhalb der Projektstruktur (nur ganz wenige Dateien) finde ich klasse, erst recht in Verbindung mit der Möglichkeit, jede Speicherung sehr einfach mit entsprechenden Kommentaren zu versehen. Dann noch das Tagging und Branching (Markieren und Verzweigen): Echt cool ! Das funktioniert sogar mit AutoCAD-Dateien, habe ich mal spasshalber ausprobiert, wäre also sogar für das "täglich' Brot" des Ingenieurs praktikabel...

@Roland: Insofern verstehe ich jetzt nicht so ganz, warum du nun so ausführlich in die Zukunft guckst, wenn dieses SVN noch so viele Hürden hat. Sicher ist es nicht verkehrt, den Fortschritt im Auge zu behalten, aber den "gewöhnlichen" Anwender wie mich verwirrt das etwas und animiert Interessierte sicher nicht, gerade jetzt mit CVS anzufangen.

[Roland Ziegler]

Hallo Frank,

in jüngster Zeit wird recht viel in den einschlägigen Medien über Subversion berichtet, manchmal überschäumend positiv, manchmal auch etwas nüchterner. Etliche solcher Beiträge sind leider oberflächlich. Da wird die Feature-List von der Subversion-Homepage abgeschrieben, ein wenig rumprobiert und fertig ist das glänzende Urteil. Solche Berichte sind es, die den Einsteiger verunsichern, und die ihn zweifeln lassen, mit CVS "noch" aufs richtige Pferd zu setzen.

Drum habe ich mir mein eigenes Urteil gebildet, dazu das ganze Zeugs installiert, als ob ich richtig damit arbeiten wollte, 200 Seiten Doku gelesen, und diverse typische Abläufe als Nutzer und als Admin einschl Repository-Backup durchgespielt.

Danach bestreite ich nach wie vor nicht die potentiellen Vorteile von SVN, halte aber gegenwärtig den geeigneten Nutzerkreis für sehr, sehr beschränkt, nämlich auf einige wenige Freaks in der Softwareentwicklung.

Erfahrungsgemäß tun sich auch etliche normale CVS-Nutzer mit Branching und Merging etwas schwer. Würde man diesen Nutzern SVN vor die Nase setzen, erscheint mit das Chaos vorprogrammiert und garantiert, schon für simples Tagging.

Deswegen: Warten wir noch ein, oder vielleicht eher zwei Jahre ab. Solange wird auch für Neueinsteiger CVS die bessere Lösung sein, gerade auch hier bei Zusi.

[Michael_Poschmann]

Erfahrungsgemäß tun sich auch etliche normale CVS-Nutzer mit Branching und Merging etwas schwer. ... das Chaos vorprogrammiert und garantiert, schon für simples Tagging.

Pssst, Roland - bitte nicht alle vertraulichen Kaffeehausgespräche direkt an die Öffentlichkeit bringen!

@ Oli: Auch wenn mein werter Vetter mir gestern beim Bier noch ein paar Tips mit auf den Weg gegeben hat, warte ich sehnlichst auf Deine angekündigte FAQ-Liste zum Thema...

Gruß
Michael

[Roland Ziegler]

Michael, keine Sorge, da haben auch einige Vollzeit-Softwareentwickler so ihre Problemchen, nicht nur selbsternannte DAUs

[Frank Wenzel]

...Warten wir noch ein, oder vielleicht eher zwei Jahre ab. Solange wird auch für Neueinsteiger CVS die bessere Lösung sein, gerade auch hier bei Zusi.

Yepp! Was mich als CVS-Laie mal interessieren würde: Tut sich denn etwas auf dem angesprochenen Sektor "ZPA" / "ZUSI-Server" oder wird CVS nur als Einzelplatzversion von "Hardcore-Oli", "Lowlevel-Frank" und ein paar anderen Hanseln benutzt?

[Oliver Lamm]

epp! Was mich als CVS-Laie mal interessieren würde: Tut sich denn etwas auf dem angesprochenen Sektor "ZPA" / "ZUSI-Server" oder wird CVS nur als Einzelplatzversion von "Hardcore-Oli", "Lowlevel-Frank" und ein paar anderen Hanseln benutzt?

Nicht zu vergessen "Chaos-Michael" *duck und weg*

Es hat sich in dieser Hinsicht nch nichts getan.

Aber wenn jemand der CVS-Nutzer gute Tipps und Tricks kennt -> Email an micht, ich möchte dazu gerne eine kleine Sammlung online stellen.

Oli

[Frank Wenzel]

...Aber wenn jemand der CVS-Nutzer gute Tipps und Tricks kennt -> Email an micht, ich möchte dazu gerne eine kleine Sammlung online stellen.
Oli

Bereits getan!

Was mich vor etwas größere Probleme stellt ist das Verschieben der "lokalen" Daten an einen anderen Speicherort (andere Partition oder auch Laufwerksordner). Dazu habe ich im Help-File nichts gefunden. Wie macht man sowas am Geschicktesten?

Hintergrund ist, dass ich die ganze Zeit meine Versuche und die ersten Projektarbeiten noch in einem separaten Zweig des "Eigene Dateien"-Bereiches betrieben habe, während ich jetzt im Streckenverzeichnis unter Zusi/Strecken/KBS650_... arbeite.

[Roland Ziegler]

Was heißt "verschieben"?

Handelt es sich um

1. lokale, von CVS bisher unbeleckte Files,
2. Files, die bereits im Repository eingecheckt sind, und in denen in der Arbeitskopie (ausgecheckt) normal editiert wird, die aber jetzt auf eine anderes Directory kommen sollen, um dort ebenfalls in einer CVS-verwalteten Arbeitskopie zu existieren,
3. eingecheckte Files, die innerhalb des Repositories verschoben werden sollen?

[Oliver Lamm]

Frank,

möchtest Du die Arbeitskopie verschieben oder das Repository ?

Antwort 1:
Kopier es einfach dahin wo Du es hinhaben möchtest.

Antwort 2:
Wie Antwort 1, nur teile nun dem CVSNT mit wo er das Repository findet.

Oli

[Gerd Schütz]

Ist jemand bekannt wie man einfach den Dateinamen ändern kann ohne die Historie zu verlieren?

Ich habe das durch editieren der entsprechenden Dateien zwar schon hinbekommen, geht es aber vielleicht auch einfacher.

Gerd

[r.h.]

Hallo Gerd,

das geht bei CVS nur manuell und selbst das ist gefährlich. CVS versteht unter umbennenen nämlich ein Löschen der alten Datei und erstellen einer neuen Datei mit neuem Namen

Mag sein, daß es PVCS oder andere anbieten. CVS definitiv nicht.

Viele Grüße,
Robert

[Gerd Schütz]

...selbst das ist gefährlich....

Wo kann da die Gefahr bestehen? Natürlich abgesehen von Schreibfehlern und vergessenen Dateieditierungen.
Vielleicht hat es bei mir bis jetzt nur auf den ersten Blick geklappt und der "Hammer" kommt erst später zum Vorschein.

CVS versteht unter umbennenen nämlich ein Löschen der alten Datei und erstellen einer neuen Datei mit neuem Namen

Aber dann verliere ich ja die Historie. Richtig?

Gruß
Gerd

[r.h.]

Wenn Du in der ,v Datei irgendetwas änderst, kann z.B. bei CVSNT das komplette Verzeichnis kaputt gehen und zwar so, daß man es gar nicht mehr auschecken kann.

Ebenso, wenn Du in der Repository-Location irgendwelche Verzeichnisnamen änderst...

Ja, Du verlierst die Historie, da es für das CVS eine neue Datei ist. Aber die Historie der alten Datei ist noch vorhanden und kann z.B. über checkout mit Datum oder Versionsangabe wieder hergeholt werden.

Robert

[Roland Ziegler]

Wie Robert schon schrieb, einfaches umbenennen ist gefährlich.

Es gibt zwei Möglichkeiten:
1. remove/add, ohne Eingriff ins Repository, Bruch der File-Historie, Erhalt der Projekt-Historie
2. Umbenennen im Repository, kein Bruch der Historie für diesen File: Aber: Verlust der Wiederherstellbarkeit alter Versionen, also Verlust der Projekt-Historie


Weg 1. Sollte klar sein. Alle Handlungen in der Arbeitskopie, File kopieren cvs-Kommandos add, remove.

Weg 2: Manipulation im Repository. Im Prinzip kannst Du die zugehörige *,v Datei im Repository einfach umbenennen. Damit heißt Dein File jetzt anders und hieß CVS mäßig immer schon anders, die Historie für diesen File bleibt erhalten. Wenn Du danach ein Update machst, bekommst eine Arbeitskopie des umbenannten Files, der Originalfile wird in der Arbeitskopie entfernt.

Theoretisch kann man im Repository den File auch kopieren. Den Original-File dann mit cvs remove entfernen.

Nochmals Achtung: Das direkte Manipulieren der Repository-Files ist riskant, wenn man sich vertut, oder nicht genau überlegt hat, was man da gerade macht.

(Sauberes Umbennenen ohne Verlust der File- und Projekt-Historie ist übrigens eine der Verbesserungen von Subversion, welches aber meiner Einschätzung nach für Normalanwender derzeit noch unbedienbar ist.)

[Gerd Schütz]

Wenn Du in der ,v Datei irgendetwas änderst, kann z.B. bei CVSNT das komplette Verzeichnis kaputt gehen und zwar so, daß man es gar nicht mehr auschecken kann.

Die ,v Datei habe ich nur umbenannt.

Ebenso, wenn Du in der Repository-Location irgendwelche Verzeichnisnamen änderst...

Da habe ich nichts geändert.

Ja, Du verlierst die Historie, da es für das CVS eine neue Datei ist. Aber die Historie der alten Datei ist noch vorhanden und kann z.B. über checkout mit Datum oder Versionsangabe wieder hergeholt werden.

Damit hast Du natürlich nicht ganz unrecht. Man hat halt nur eine Datei mehr. Ich werde mal darüber nachdenken.

Im Prinzip kannst Du die zugehörige *,v Datei im Repository einfach umbenennen

Braucht man nur diese Datei umbennen?
Ich habe nämlich in der Datei \Cvsroot\history auch den Dateinamen geändert.

Gerd

[Roland Ziegler]

Das Zeugs in \history sollte man nicht anpacken müssen.

Das history-Dir nicht verwechseln mit ,v-Files, die in der CVS-Doc als History-File bezeichnet werden.

Hier der Link auf die offizielle Doc:
https://www.cvshome.org/docs/manual/cvs ... html#SEC70

(kann man sich auch als pdf runterladen.)

[Gerd Schütz]

Danke Roland,

Schaue ich mir mal genauer an.

Gerd

[Frank Wenzel]

Leicht verspätet :

Was heißt "verschieben"?

Handelt es sich um

1. lokale, von CVS bisher unbeleckte Files,
2. Files, die bereits im Repository eingecheckt sind, und in denen in der Arbeitskopie (ausgecheckt) normal editiert wird, die aber jetzt auf eine anderes Directory kommen sollen, um dort ebenfalls in einer CVS-verwalteten Arbeitskopie zu existieren,
3. eingecheckte Files, die innerhalb des Repositories verschoben werden sollen?

Ich meinte Nr. 2! Ich habe es so gemacht, wie es Oli unter Antwort 1 beschrieben hat, aber trotzdem hat es etwas gehakt. Schließlich habe ich es doch hinbekommen, frag' mich aber nicht mehr wie...

Zum Thema "Umbenennen": Bei manchen Dingen darf man unter Verwendung von CVS nicht die üblichen Dateioperationen und Tricks anwenden, das habe ich inzwischen auch erfahren müssen:

Gestern habe ich bemerkt, dass mein Modul gegenüber dem Referenzmodul die falschen UTM-Koordinaten besaß. Händisches Editieren der Angaben in der STR-Datei brachte mich nicht weiter, so habe ich zu dem Trick gegriffen, aus der Ref.-Datei das Anschluss-Element zu isolieren. Die falsch positionierte STR-Datei habe ich temporär umbenannt, dann das isolierte Element aus der Refernenz-Datei in die originale STR-Datei umbenannt und schließlich die temporäre Datei importiert und alles gespeichert. Faktisch was alles i. O., wie ich in TRANSDEM sehen konnte, aber das Repositiory verweigert das Einchecken der neuesten Daten. Ich versuche jetzt mal, die gesamte ursprüngliche Datei mit den ZUSI-Bordmitteln richtig zu platzieren, ohne die Originaldatei zu vergewaltigen...

[Roland Ziegler]

ch meinte Nr. 2! Ich habe es so gemacht, wie es Oli unter Antwort 1 beschrieben hat, aber trotzdem hat es etwas gehakt. Schließlich habe ich es doch hinbekommen, frag' mich aber nicht mehr wie...

Wenn man Arbeitskopien verschiebt, dann immer mit dem CVS-Subdirectory. Genauso kann man natürlich auch neu auschecken, einen Pfad irgendwo anders hin. TortoiseCVS ist etwas geizig mit dem Anbieten des Checkout-Kommandos. Es erscheint nur in Verzeichnissen, die noch nicht unter CVS-Verwaltung stehen. (Ggf. kann man auf die Konsole zurückgreifen. Die Explorer-Erweiterungs-.reg habe dafür ich gestern gepostet, und den Link auf die vollständige CVS-Doku weiter oben hier.)

Faktisch was alles i. O., wie ich in TRANSDEM sehen konnte, aber das Repositiory verweigert das Einchecken der neuesten Daten.

Wie äußert sich das Problem? Umbenennen oder Kopieren ist lokal durchaus erlaubt. Die neu benannten/erstellten Files sind natürlich erst mal nicht unter CVS-Kontrolle. Benennt man dann später wieder zurück, also in einen Namen, der von CVS verwaltet wird, wird TortoiseCVS das erkennen. Was man nicht und nie machen darf, ist im CVS-Subdirectory hermumwurschteln. Deswegen wird das normalerweise auch als versteckt markiert. Was auch schief geht, ist ein Kopieren/Verschieben von Directories mit CVS-verwalteten Files in eins ohne CVS, aber mit (teilweise) denselben Filenamen. Das führt zu üble Konflikten. Für solche Fälle gibt es dann die CVS-Export-Funktion.