>>164223Das liegt daran, dass CVS kein gewissenhaft designtes Produkt, sondern das Ergebnis organischer Unix-Frickelscheiße ist.
Ursprünglich gab es gar keine strukturierte Versionsverwaltung und es wurden höchstens durchnummerierte Dateien benutzt. Irgendwann kam man dann auf die Idee, das diff-Programm zu automatisieren. Das war der Ursprung des Urvaters RCS, das die Versionskontrolle individueller Dateien ermöglicht hat (weil diff ursprünglich nur ein Paar von Dateien vergleichen konnte). Die Datei foobar.c wich dabei dem Masterfile RCS/foobar.c,v das schreibgeschützt war und nur nach einem Checkout (aktuelle Version rekonstruieren + Lockfile erstellen) Änderungen erlaubt hat. Das Masterfile-Format ist dabei nur ein Haufen zusammengeklebte diff-Patches mit Kontrollzeilen (Autor, Zeitstempel, Commit-Nachricht).
Bei CVS handelt es dann eigentlich nur um Mehrspieler-RCS, das u. a. eine Netzwerk-Schnittstelle ergänzt und das harte Locking zugunsten einer lokalen Arbeitskopie und Konflikt-Auflösungsalgorithmen aufgibt. Außerdem hat CVS ein Konzept von Modulen, dass ein Satz von Dateien irgendwie zusammengehört. Die Metadaten darüber (z. B. CVS/Entries, das alle zugehörigen Dateien mit neuster Version aufführt) wurden ebenfalls als Masterfiles versioniert.
Das Konzept hat bis in die frühen 90er halbwegs gut funktioniert, als ein Entwickler immer an einer oder wenigen Quelldateien gleichzeitig gewerkelt hat und die externen Abhängigkeiten anderer Entwickler als gottgegeben hingenommen hat. Bei größeren Software-Projekten stieß man aber damit an seine Grenzen und so entstanden zwei Lager, die kommerziellen Systeme wie Perforce und Bitkeeper, die ohne größere Probleme mit dem RCS-Format interagieren konnten, und klägliche Versuche, Patchsets (Diffs für mehrere zusammenhängende Dateien, so wie Commits in git) und Branches mithilfe von RCS/CVS zu verwalten. Die Opensource-Community fing sich erst wieder, als sich Projekte wie Subversion durchsetzen konnten.