nicht angemeldet
CVS / TortoiseCVS und Marken
Hallo!
Vielleicht habe ich es nicht ganz verstanden...
Ich möchte Marken vergeben, STABLE, Main TEST und DEVEL.
Versionssummer: STABLE.Main.TEST.DEVEL // Bsp: 1.3.28.2
Wenn ich in ein Dokument $Revision$ setze, wird mir aber nur 1.3 angezeigt. Ich muß ja sicherlich irgendwie dem System beibringen das die Versionsnummer STABLE.Main.TEST.DEVEL in mein Dokument geschrieben wird.
Ich habe CVS und TortoiseCVS http://www.xwolf.de/artikel/cvstutor/ ans laufen bekommen.
Bei den Marken hänge ich.
MfG, André Laugks
--
L-Andre @ gmx.de
L-Andre @ gmx.de
-
Moin!
Vielleicht habe ich es nicht ganz verstanden...
Könnte sein. :)
Ich möchte Marken vergeben, STABLE, Main TEST und DEVEL.
Versionssummer: STABLE.Main.TEST.DEVEL // Bsp: 1.3.28.2
Du meinst "Versionsnummern"? Die kannst du normalerweise in CVS nicht vergeben, die werden unabhängig verwaltet.
Das soll dich aber natürlich nicht daran hindern, noch eine eigene Numerierung parallel zu führen - die ist dann aber eigentlich nur aus "Marketinggründen" da.
Wenn ich in ein Dokument $Revision$ setze, wird mir aber nur 1.3 angezeigt. Ich muß ja sicherlich irgendwie dem System beibringen das die Versionsnummer STABLE.Main.TEST.DEVEL in mein Dokument geschrieben wird.
Die $Revision$ zeigt die CVS-Versionsnummer. Die ist bei ganz normalen Projekten ohne Verzweigungen immer zweistellig, wobei sich die zweite Stelle mit jedem vorgenommenen Commit dieses Files um eins erhöht.
Vierstellige Versionsnummern in CVS entstehen, wenn man einen Ableger einer Datei anlegt (branch), beispielsweise um ausgehend von der Entwicklungsfront einen Stand unter Feature-Freeze bis zum einsatzfähigen Stadium weiterzuentwickeln, während die Entwicklung neuer Features parallel am Hauptstrang weitergeht. Die ersten beiden Ziffern entsprechen der Version, von er aus abgezweigt wurde, die letzten beiden stehen für den aktuellen Stand im Branch, und die letzte Stelle wird bei Commits wieder um eins erhöht.
Löse dich von der Vorstellung, die CVS-Versionsnummer wäre irgendeine Zahl mit Relevanz. Das ist ein intern mitlaufender Zähler, der für jede Datei einzeln gezählt wird, um die Versionen auseinanderhalten zu können, es hat aber absolut nichts mit "Versionsnummern" zu tun, wie sie zur Beschreibung eines Softwarereleases genutzt werden.
Denn wenn eine Datei nach dem initialen Commit mit Version 1.1 im CVS steht und während der gesamten Entwicklungsarbeit nie verändert wird, so wird sie am Ende dennoch in einem Softwareprojekt mitwirken, das die "Verkaufsversionsnummer" 2.4.16-r3 hat. Da die einzelnen Dateien sowieso alle unterschiedliche Nummern haben, ist die CVS-Version somit ohnehin unbrauchbar, was diese Angaben angeht.
Wenn du im CVS später den Versionsstand wiederfinden willst, der zu einer bestimmten veröffentlichten Version geführt hat, dann benutze Tags und schreibe in den Tagnamen die Versionsnummer der Veröffentlichung rein. Anders kriegst du es nicht hin, genau die Dateiversionen später auszuchecken, die damals zum Build genutzt wurden.
Ich habe CVS und TortoiseCVS http://www.xwolf.de/artikel/cvstutor/ ans laufen bekommen.
Solltest du tiefer einsteigen wollen (ich fand das zumindest ganz informativ), empfehle ich dir http://cvsbook.red-bean.com/. Ist englisch und behandelt im ersten Teil CVS sehr ausführlich, erklärt auch vieles (beispielsweise den Grund für die "Vendor"-Angaben) und hat hilfreiche Tipps für "wie macht man denn am besten...".
- Sven Rautenberg
-
Moin!
Solltest du tiefer einsteigen wollen (ich fand das zumindest ganz informativ), empfehle ich dir http://cvsbook.red-bean.com/. Ist englisch und behandelt im ersten Teil CVS sehr ausführlich, erklärt auch vieles (beispielsweise den Grund für die "Vendor"-Angaben) und hat hilfreiche Tipps für "wie macht man denn am besten...".
Gerade gesehen: Auf der Seite ist auch ein Link zu einer deutschen Übersetzung. :)
- Sven Rautenberg
-
Hi Sven!
Mal ne kurze Frage am Rande: Würdest Du für ein neues Web-Projekt heute CVS oder SVN wählen? SVN hat IMHO zwar einige Vorteile, auf der anderen Seite ist die Software IMHO noch nicht ganz so solide wie bei CVS. Was würdest Du im Moment einsetzen?
Grüße
Andreas--
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/-
Moin!
Mal ne kurze Frage am Rande: Würdest Du für ein neues Web-Projekt heute CVS oder SVN wählen? SVN hat IMHO zwar einige Vorteile, auf der anderen Seite ist die Software IMHO noch nicht ganz so solide wie bei CVS. Was würdest Du im Moment einsetzen?
Ich habe für meine Firma CVS im Einsatz, weil ich das "damals" als erstes entdeckt hatte und SVN noch kein Thema war.
Für SELFHTML 8.1 und das Classic Forum ist SVN im Einsatz, welches zwar durch etwas mehr Benutzer und etwas häufigere Commits strapaziert wird, sich aber bislang auch irgendwie durch eine höhere Instabilität ausgezeichnet hat. Verlorengegangen ist zwar nichts, aber Unverfügbarkeit ist ja auch nicht schön. CK sitzt da aber dran.
Insofern werde ich persönlich auch in naher Zukunft lieber CVS verwenden - das ist so schön einfach installiert und funktioniert. Mit SVN habe ich mich einfach noch zu wenig beschäftigt.
- Sven Rautenberg
-
-
Hallo!
Du meinst "Versionsnummern"? Die kannst du normalerweise in CVS nicht vergeben, die werden unabhängig verwaltet.
Die $Revision$ zeigt die CVS-Versionsnummer. Die ist bei ganz normalen Projekten ohne Verzweigungen immer zweistellig, wobei sich die zweite Stelle mit jedem vorgenommenen Commit dieses Files um eins erhöht.
Das ist mir klar, auch der inkrementel durchlaufen.
Vierstellige Versionsnummern in CVS entstehen, wenn man einen Ableger einer Datei anlegt (branch), beispielsweise um ausgehend von der Entwicklungsfront einen Stand unter Feature-Freeze bis zum einsatzfähigen Stadium weiterzuentwickeln, während die Entwicklung neuer Features parallel am Hauptstrang weitergeht.
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.
Löse dich von der Vorstellung, die CVS-Versionsnummer wäre irgendeine Zahl mit Relevanz. Das ist ein intern mitlaufender Zähler, der für jede Datei einzeln gezählt wird, um die Versionen auseinanderhalten zu können, es hat aber absolut nichts mit "Versionsnummern" zu tun, wie sie zur Beschreibung eines Softwarereleases genutzt werden.
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.
DEVEL -> 0.0.0.1
DEVEL -> 0.0.0.2
DEVEL -> 0.0.0.3
TESR -> 0.0.1.3 // oder 0.0.1.0
MAIN -> 0.1.0.0
STABLE -> 1.0.0.0Bei einem Ausschecken möchte ich dann alle Dateien haben die ich als STABLE eingestruft habe.
Da die einzelnen Dateien sowieso alle unterschiedliche Nummern haben, ist die CVS-Version somit ohnehin unbrauchbar, was diese Angaben angeht.
Genau das ist mir gestern auch so in den Sinn gekommen.
Wenn du im CVS später den Versionsstand wiederfinden willst, der zu einer bestimmten veröffentlichten Version geführt hat, dann benutze Tags und schreibe in den Tagnamen die Versionsnummer der Veröffentlichung rein. Anders kriegst du es nicht hin, genau die Dateiversionen später auszuchecken, die damals zum Build genutzt wurden.
Mhhh, da komme ich jetzt nicht ganz mit.
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.
MfG, André Laugks
--
L-Andre @ gmx.de
-
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
-
Hallo!
[...]
Vielen Dank für Deine Ausführungen.
Genau das mit den Zweigen brauche ich.
Dann lies das verlinkte Buch unbedingt.
Werde ich!
Den TortoiseCVS & Co. treibt mich in den Wahnsinn. TortoiseCVS sagt es gebe Konflikte, wenn ich die Konflikte auflösen möchte, gibt es auf einmal keine mehr. Dann kann ich Dateien nicht einchecken, weil sie anscheint noch ein anderer Benutzer bearbeitet. Ich bin der einzige Benutzer...
Alles ein Elend! ;-=
MfG, André Laugks
--
L-Andre @ gmx.de
-
Moin!
Den TortoiseCVS & Co. treibt mich in den Wahnsinn. TortoiseCVS sagt es gebe Konflikte, wenn ich die Konflikte auflösen möchte, gibt es auf einmal keine mehr. Dann kann ich Dateien nicht einchecken, weil sie anscheint noch ein anderer Benutzer bearbeitet. Ich bin der einzige Benutzer...
Wo liegen deine Dateien? Netzwerklaufwerk? Das sorgt für Probleme, mindestens für Uhrzeitprobleme. Windows ist da leider nicht so intelligent programmiert und zählt die Zeit immer als lokale Zeit, anstatt wie bei Windows als Greenwich-Zeit plus Zeitzonenverschiebung. Da CVS die Unverändertheit einer Datei an ihrem Veränderungsdatum feststellt, ist das natürlich böse.
Eigentlich funktioniert TortoiseCVS aber ganz prima.
- Sven Rautenberg
-
-