Ein Wiki privater Natur

CVS

ein paar Gedanken und Tips

Die ausführliche Dokumentation ist hier:

https://web.mit.edu/gnu/doc/html/cvs_toc.html
Die will und kann ich nicht ersetzen.

Keywords

Man kann im Kopf seines Codes Keywörter benutzen, die bei Check in aktualisiert werden.

Keywörter: "$Revision$", "$Date$" und "$Log$"

Und ein ganz wichtiger Tip für nano als cvs Editor:

Bei mir, debian Trixie, ist nano in der Version 8.0-1
Ich habe das Phänomen, dass der nano eine andere Tastatur Key Belegung hat, wenn er als Editor für CVS herhalten muss. Da ist Strg-q zum Beenden.
Fix:
export CVSEDITOR="nano --ignorercfiles"

Löst das Problem!

Warum CVS

Warum ich bei CVS bleibe.
Ich fühle mich damit wohl und entspricht meinen Anforderungen.
CVS hat sich ja bewährt
und erfüllt in vielen Fällen immer noch seinen Zweck.
GitLab und ähnliche Plattformen haben definitiv ihre Vorteile, besonders in
Teamumgebungen und bei größeren Projekten.
Sie bieten Features wie Issue-Tracking, Merge-Requests, CI/CD-Pipelines und mehr, die den Entwicklungsprozess erleichtern können.
Aber da ich allein arbeite und die volle Kontrolle über meine
Daten behalten möchte, ist CVS eine völlig ausreichende und passende Lösung.
Bekanntheit und Komfort: Ich kenne CVS in- und auswendig und bin damit effizient.
Datenkontrolle: Ich behalte die volle Kontrolle über meine Repositories und
brauche keine externen Dienste.
Einfachheit: Für kleinere Projekte und Solo-Entwicklung reicht CVS völlig aus.
Legacy-Unterstützung: Viele ältere Projekte sind darin versioniert.
Ein Wechsel würde zusätzlichen Aufwand bedeuten.

Aufsetzen eines CVS Repositorys

Derzeit noch hier:
https://zockertown.de/s9y/index.php?/archives/1714-CVS-einrichten.html

Grundlegende Commandos

Merken sollte man sich

Beim cvs update Befehl gibt es verschiedene Buchstaben, die anzeigen, was mit den Dateien passiert ist.

U: Update - Die Datei wurde vom CVS-Server aktualisiert.
M: Modified - Die Datei wurde lokal geändert, aber noch nicht ins Repository eingecheckt.
A: Added - Die Datei wurde zur CVS-Überwachung hinzugefügt, aber noch nicht ins Repository eingecheckt.
P: Patched - Die Datei wurde durch Anwenden eines Patches vom Server aktualisiert.
Dies geschieht, wenn die Änderungen zwischen der Version auf dem Server und der
lokalen Version so klein sind, dass ein Patch ausreicht, um die Dateien zu
synchronisieren.

Für Nautilus habe ich ein Script geschrieben,
das ist ganz praktisch, wenn man GUI liebt.

nautilus-helper-scripte

eine ältere Revision auschecken

Hier im Beispiel ein shellscript mit Namen run_with_nvidia.sh in der Version 1.4
Das Script hat Fehler und man will doch wieder die vorherige Version als aktuelle haben

- cvs status run_with_nvidia.sh

===================================================================
File: run_with_nvidia.sh	Status: Up-to-date

   Working revision:	1.4
   Repository revision:	1.4	/var/CVS/Scripte/run_with_nvidia.sh,v
   Commit Identifier:	1006784101A475FFD1D
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

- cvs diff -r 1.3 run_with_nvidia.sh

Index: run_with_nvidia.sh
===================================================================
RCS file: /var/CVS/Scripte/run_with_nvidia.sh,v
retrieving revision 1.3
retrieving revision 1.4
diff -r1.3 -r1.4
4c4
< # Version $Revision: 1.3 $
---
> # Version $Revision: 1.4 $
7a8
> # Das ist Version 1.4, jedenfalls, wenn ich das einchecke

(Hier sieht man auch eine Erweiterte Variante. Mit cvs diff -r 1.2 -r 1.3 kann man auch zwischen Versionen mittendrin die Diff bilden.)

- cvs update -r 1.3 run_with_nvidia.sh

P run_with_nvidia.sh

- cvs status run_with_nvidia.sh

===================================================================
File: run_with_nvidia.sh	Status: Up-to-date

   Working revision:	1.3
   Repository revision:	1.3	/var/CVS/Scripte/run_with_nvidia.sh,v
   Commit Identifier:	10067840EEA33FB12E3
   Sticky Tag:		1.3
   Sticky Date:		(none)
   Sticky Options:	(none)

Hier erhält man die Bestätigung: Version 1.4 ist Geschichte. Man achte auf das Sticky Tag:

Nach der Korrektur bzw. Erweiterungdes Scriptes sollte man das Script wieder einchecken, doch ...

- cvs ci run_with_nvidia.sh

cvs commit: sticky tag `1.3' for file `run_with_nvidia.sh' is not a branch
cvs [commit aborted]: correct above errors first!
cvs commit: your log message was saved in /var/tmp/cvsn10lbt

Das funktioniert nicht! ... Das Sticky Tag!

Deshalb muss man explizit das Sticky Tag ignorieren mit "-A"

- cvs update -A run_with_nvidia.sh

Was aber dann die Folge hat, dass alles ist, wie vorher, also 1.4 wieder da ist

- cvs update -p -r 1.3 run_with_nvidia.sh > run_with_nvidia.sh

===================================================================
Checking out run_with_nvidia.sh
RCS:  /var/CVS/Scripte/run_with_nvidia.sh,v
VERS: 1.3
***************

Damit holt man den Inhalt der Version 1.3 und überschreibt die Arbeitskopie. Achtung: Das macht den Arbeitsbereich unverankert!

Nun die Änderungen durchführen und mit

- cvs ci run_with_nvidia.sh

einchecken

- cvs status run_with_nvidia.sh

===================================================================
File: run_with_nvidia.sh	Status: Up-to-date

   Working revision:	1.5
   Repository revision:	1.5	/var/CVS/Scripte/run_with_nvidia.sh,v
   Commit Identifier:	1006784E3748AA63AB3
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

Wichtig: CVS ist ein lineares Versionskontrollsystem. Ein direktes "Überschreiben" oder Löschen von 1.4 ist nicht möglich. Was hier gemacht wurde, ist eine Revision auf Basis von 1.3 neu zu erzeugen.

Und wie ändert man den Namen einer eingecheckten Datei?

Der normale Weg zum Umbenennen
Der normale Weg, eine Datei zu verschieben, besteht darin, die alte Datei nach der neuen zu kopieren und dann die normalen CVS-Befehle auszuführen, um die alte Datei aus dem Repository zu entfernen und die neue hinzuzufügen. (Sowohl alt als auch neu können relative Pfade enthalten, zum Beispiel foo/bar.c

$ mv alt neu
$ cvs remove old
$ cvs hinzufügen neu
$ cvs commit -m "Umbenannt von alt nach neu" alt neu
Dies ist der einfachste Weg, eine Datei zu verschieben, er ist nicht fehleranfällig und bewahrt die Historie des Vorgangs. Beachten Sie, dass Sie für den Zugriff auf die Historie der Datei den alten oder den neuen Namen angeben müssen, je nachdem, auf welchen Teil der Historie Sie zugreifen wollen. Zum Beispiel liefert cvs log old das Protokoll bis zum Zeitpunkt der Umbenennung.

Wenn new übertragen wird, beginnen die Revisionsnummern wieder bei 1.0. Wenn Sie das stört, verwenden Sie die Option -r rev, um zu übertragen (siehe Abschnitt Optionen für die Übertragung).

Ins Deutsche übersetzt von https://web.mit.edu/gnu/doc/html/cvs_14.html#SEC64