nicht angemeldet
Moin!
Genau das möchte ich machen. Ich möchte eine Version als stabil "einstufen". Möchte aber parallel an der Version weiter arbeiten.
Aber "branch" ist ein gutes Stichwort.
CVS kann auch sechsstellige, achtstellige etc. Versionsnummern haben, wenn man im Branch wieder abzweigt. Ist aber nicht unbedingt empfehlenswert und auch nur selten wirklich notwendig.
Mal in eigenen Worten, was ein Branch macht:
Du fängst mit dem Programmieren an und packst erstmal ein paar Features rein. Die sind zuerst noch fehlerhaft, werden aber mit der Zeit immer besser.
Irgendwann denkst du dir, dass der jetzige Stand eigentlich veröffentlichungsreif ist. In diesem Moment erzeugst du einen Branch. Das bedeutet: Der Hauptstrang der Entwicklung geht mit zweistelligen CVS-Versionen weiter (dort kommen auch neue Features rein, die zuerst natürlich wieder extrem buggy sind), und der Abzweig ist die Version, welche mit den bis dahin definierten Features nur noch in Richtung "fehlerfrei" getrimmt wird.
Wenn wir mal Mozilla als Beispiel nehmen: Dort wäre ein Branch beispielsweise jede der bisher erschienenen Versionen 1.0, 1.1, 1.2,... 1.7. Dort gibts aber nach der ersten Version 1.7 auch immer noch Bugfixes und evtl. kleine Weiterentwicklungen, beispielsweise für neue Plattformen. Also würde die Version 1.7 wieder als Hauptstrang betrachtet werden können, von dem irgendwann Unterversionen wieder in Richtung "irgendwann fertig entwickelt" abzweigen, während der Hauptstrang 1.7 sich auch weiterentwickelt.
Soweit zu Branches. Bleiben noch Tags. Das sind Markierungen, die für den Zugriff auf ganz bestimmte CVS-Versionen notwendig sind.
Beispielsweise ist es extrem empfehlenswert, dann ein Tag zu setzen, wenn man den aktuellen Stand der Entwicklung in dem Zweig (sei es der Hauptstrang oder ein Branch) in eine fertige Version kompiliert (oder zippt). Dann kann man später immer exakt diese Version von allen Dateien wieder einlesen und von dort aus z.B. Bugfixes vornehmen oder sich noch mal ansehen, welche Quelltextversion denn tatsächlich in die Veröffentlichung kam.
Ebenso ist es extrem ratsam, genau dann ein Tag zu setzen, wenn man einen Branch anlegt. Denn wenn man statt des Hauptzweiges den Branch lädt, kriegt man auch dort nur die aktuellste Version, man kommt aber ohne Tag niemals zu dem Versionsstand hin, der bestand, als der Branch angelegt wurde. Da es durchaus sein kann, dass man später Bugfixes des Branchs wieder zurück in den Hauptstrang einfließen lassen möchte (beispielsweise weil sich in einer benutzten Bibliothek, an der sich nie was geändert hat, ein Fehler gefunden hat, der zuerst mal in der aktuellen Version korrigiert wurde), macht man sich das Leben wesentlich einfacher, wenn man das Tag zum Zeitpunkt des Branches hat.
Ich hatte mir das so gedacht, daß ich eine Versionsnummer wie STABLE.Main.TEST.DEVEL vergebe bzw. CVS mir die dann reagiert. Je nach dem wie ich eine Datei einstufe wird der Teil um einer Nummer erhöht und ich dann so den Stand erkennen kann.
Du kannst Tags vergeben. Darin kannst du solche Markierungen reinschreiben (wobei Punkte als Zeichen nicht erlaubt sind - mit Unterstrichen oder ohne Punkte überlebt man das aber).
Außerdem sind solche Bezeichnungen eigentlich sowieso nur projektübergreifend sinnvoll, denn entweder das gesamte Projekt ist noch DEVEL, oder es ist STABLE. Ein Projekt, in dem eine Komponente ihrerseite noch DEVEL ist, kann nicht STABLE sein. :)
Bei einem Ausschecken möchte ich dann alle Dateien haben die ich als STABLE eingestruft habe.
Was ist mit den restlichen Dateien, die wichtig sind, um das Projekt überhaupt kompilieren zu können (kompilieren sei hier mal ein Synonym für "komplett unf funktionsfähig haben")?
Wenn du nicht ein Riesenprojekt haben willst, sondern die Möglichkeit, mehrere Einzelkomponenten unabhängig voneinander zu entwickeln, die auch unabhängig voneinander stabil werden können, dann brauchst du mehrere CVS-Repositorien dafür. Dann kannst du Komponenten unabhängig voneinander taggen und somit auch als stabil deklarieren. Sowas macht aber in der Regel nur Sinn, wenn diese Komponenten tatsächlich auch einzeln sinnvoll genutzt werden können, sie also hinreichend unabhängig vom Rest sind.
Solltest du tiefer einsteigen wollen (ich fand das zumindest ganz informativ), empfehle ich dir http://cvsbook.red-bean.com/.
Ja ich möchte tiefer einsteigen, weil das wohl ein langjähriges Projekt wird.
Dann lies das verlinkte Buch unbedingt. Mit CVS zu arbeiten ist eine gewisse Umstellung. Man kann sich das Leben damit vereinfachen, man kann es sich aber auch unnötig erschweren, wenn man Dinge vergisst. Den normalen Programmierer, der ein Repository vorgesetzt bekommt und dorthinein seine Veränderungen committet, den interessiert das ganze Trara um Branches und Tags vielleicht nicht sonderlich, solange er dafür nicht verantwortlich ist. Da mir aber scheint, dass du auch der Admin des CVS sein wirst, ist es immer gut, wenn man ein bißchen was weiß. :)
- Sven Rautenberg