ein paar Gedanken und Tips
https://web.mit.edu/gnu/doc/html/cvs_toc.html
Die will und kann ich nicht ersetzen.
Man kann im Kopf seines Codes Keywörter benutzen, die bei Check in aktualisiert werden.
Keywörter: "$Revision$", "$Date$" und "$Log$"
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 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.
Derzeit noch hier:
https://zockertown.de/s9y/index.php?/archives/1714-CVS-einrichten.html
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.
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
===================================================================
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)
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.)
P 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 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"
Was aber dann die Folge hat, dass alles ist, wie vorher, also 1.4 wieder da ist
===================================================================
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
einchecken
===================================================================
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.
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