CVS kann eine Menge Dinge für Sie tun, aber CVS versucht
nicht alles für jeden zu tun.
- CVS ist kein Build System.
Die Struktur Ihres Repositorys und ihrer Module Datei
sind mit Ihrem Build System verknüpft (bspw. `Makefile's),
sind aber essentiell unabhängig voneinander.
CVS schreibt Ihnen nicht vor, wie Sie etwas Erstellen.
Es speichert lediglich Dateien zur Wiederherstellung einer
Baum Struktur die Sie vorgeben.
CVS schreibt Ihnen nicht vor, wie Sie Ihren Plattenplatz
in ausgecheckten Verzeichnis verwenden. Wenn Sie Ihre
`Makefile's oder Scripte in jedem Verzeichnis schreiben,
so müssen diese die relative Position zu allem anderen kennen,
das kann dazu führen, daß Sie das vollständige Repository
auschecken müssen.
Wenn Sie Ihre Arbeit modularisieren, und ein Build--System
erzeugen, das Dateien shared (via links, mounts,
VPATH in `Makefile's, etc.) so können Sie Ihre
Plattenbenutzung so arrangieren wie Sie es möchten.
Sie sollten aber daran denken, daß jedes System in
dieser Art, einen Haufen Arbeit bei der Erstellung
verursacht und auch die Pflege. CVS ist nicht für
dieser Art von Aufgaben konzipiert worden, die im
Zusammenhang damit entstehen.
Selbstverständlich, sollten Sie solche Tools die zur
Unterstützung eines Build--System erzeugt wurden
(Scripte, `Makefile's, etc. ) unter die Kontrolle von
CVS stellen.
Um heraus zu finden, ob Dateien neu erstellt werden müssen
wenn sich etwas ändert, ist etwas das ausserhalb von
CVS gehandhabt werden muß. Ein traditioneller
Ansatz ist, daß zur Erstellung make verwendet
wird und ein automatisiertes Tools, um die Abhängigkeiten
zu erstellen, die make verwendet.
Sehen Sie unter 14. How your build system interacts with CVS nach, um weitere Informationen
bezüglich der Erzeugung in Verbindung mit CVS zu
erhalten.
- CVS ist kein Ersatz für Management
Von Ihren Managern und Projekt--Leitern wird erwartet,
daß mit Ihnen häufig genug ein Austausch stattfindet
damit sichergestellt ist, daß Ihnen Abläufe,
Zusammenführungspunkte, Verzeigungen in der Entwicklung
und Release Daten bekannt sind. Wenn das nicht gemacht wird,
kann Ihnen CVS auch nicht helfen.
CVS ist ein Instrument, damit die Quellen nach Ihrer
Pfeife tanzen. Aber Sie sind der Pfeifer und Komponist. Kein
Instrument spielt von selbst oder schreibt seine eigene Musik.
- CVS ist kein Ersatz für Entwickler Kommunikation
Wenn Entwickler mit Konflikten innhalb einer Datei
konfrontiert werden, dann wird das unter den Entwicklern
gelöst ohne großes Aufheben. Aber eine mehr allgemeine
Definition von Konflikten beinhaltet Probleme, welche
zu komplex sind um sie ohne eine Kommunikation der Entwickler
unter einander zu lösen.
CVS ist nicht in der Lage festzustellen, ob innerhalb
einer Datei oder über eine Kollektion von Dateien
gleichzeitig veränderungen vorgenommen werden, die sich
logisch widersprechen. Das Konzept des Konfliktes
(conflict) ist rein textualer natur, die auftritt,
wenn zwei Änderungen an der gleichen Datei so nah einander
sind, daß das Mergen (i.e. diff3) verhindert
wird.
CVS ist nicht in der Lage Konflikte im Bereich
non-textualen oder in verteilten Konflikten der
Programmlogik zu helfen.
Beispielsweise sagen wir, Sie ändern die Argumente der
Funktion X, die in der Datei `A' definiert
ist. Zur gleichen Zeit editiert jemand die Datei `B'
und fügt einen neuen Aufruf der Funktion X hinzu,
unter Verwendung der alten Argumente. Das ist außerhalb
der Kompentenz von CVS.
Hat jemand eine gute Idee, wie man das hier übersetzt:
Gewöhnen Sie sich an, Spezifikationen zu lesen und
mit Ihren Kollegen zu reden.
- CVS hat keine change control(1)
Change control kann vieles bedeuten. Es kann zuerst
einmal bug-tracking heißen, einen Datenbestand
zu haben, in dem gefundene Fehler festgehalten werden und
der Zustand eines jeden (Ist der Fehler schon behoben? In
welcher Release war er? War der, der den Fehler gemeldet
hat, damit einverstanden ihn als erledigt zu
kennzeichnen?). Um nun CVS zur zusammenarbeit mit
einem externen bug-tracking System zu ermöglichen sollten
Sie sich `rcsinfo' und die `verifymsg' Datei
ansehen ( C. Reference manual for Administrative files).
Ein anderer Aspekt von change control ist die
Möglichkeit, das Änderungen an vielen Dateien
tatsächlich im Zusammenhang mit einer logischen
Änderung stehen und als solche nachvollziehbar sein
sollten. Wenn Sie mehrere Dateien durch ein einziges
cvs commit einchecken, vergisst CVS danach,
daß diese Dateien gemeinsam eingecheckt wurden. Die
Tatsache, daß die Dateien die gleiche Log Nachricht
haben, ist der einzige Hinweis auf diesen Zusammenhang.
Wenn Sie eine GNU `ChangeLog' Datei führen,
kann Ihnen das in dieser Situation ein wenig helfen.
Ein anderen Aspekt von change control in einigen
Systemen ist die Möglichkeit den Zustand einer jeden
Änderung festzuhalten. Einige Änderungen wurden durch
den Entwickler gemacht andere wurden durch weitere
Überprüfungen eines anderen Entwicklers durchgeführt
und so weiter. Die allgemeine Vorgehensweise mit CVS
ist die der Erzeugung eines diffs (unter Verwendung von
cvs diff bzw. diff) und die Versendung
via email an jemand anderen. Das ist eine sehr flexible
Methode, liegt aber außerhalb der Verantwortung von
CVS und muß durch entsprechende Methoden vereinbart
werden.
- CVS ist kein automatisches Testprogramm
Es sollte möglich sein, ...
It should be possible to enforce mandatory use of a
testsuite using the `commitinfo' file. I haven't
heard a lot about projects trying to do that or whether
there are subtle gotchas, however.
- CVS hat kein integriertes Vorgehensmodell
Einige Systeme bieten Möglichkeiten, um sicherzustellen,
daß Änderungen oder Releases bestimmten Prüfungen
unterzogen werden.
Some systems provide ways to ensure that changes or
releases go through various steps, with various
approvals as needed. Generally, one can accomplish
this with CVS but it might be a little more work.
In some cases you'll want to use the `commitinfo',
`loginfo', `rcsinfo', or `verifymsg'
files, to require that certain steps be performed
before cvs will allow a checkin. Also consider whether
features such as branches and tags can be used to
perform tasks such as doing work in a development tree
and then merging certain changes over to a stable tree
only once they have been proven.
