Newmake goes Head [ab 06.01.2009]

[dbt]

...
die hostapps (von denen div. auch veraltet sind) in einen extra branch legen.

Davon würde ich abraten. Die werden schon gebraucht. Es gibt zwar einige einzelne Projekte wie zB. in Win32, die keine Rolle beim bauen spielen, wo man das durchaus machen könnte, aber so viel macht das dann auch nicht aus.

[rhabarber1848]

die hostapps (von denen div. auch veraltet sind) in einen extra branch legen.

Davon würde ich abraten.

+1

[Barf]

Der Ist-Zustand beim CDK-Development ist alles anders als fruchtbar für Entwicklung und Entwickler. Wie man oft von Postings von z.B. seife erfahren hat, kostet es sehr viel Energie und Kreativität, nicht "nur" tolle Sachen in einem technologoschen gesunden Umgebung einzuchechen, sondern auch zu vergewissern, dass auch eine andere Buildzweig unterhalten wird, und nicht damit "kaputtgeht".

Diese Energie und Kreativität könnte besser benutzt werden. Sicherlich wird dadurch die Rekrutierung von neuen Entwickler nicht gerade vereinfacht. Das "zweigleichigge Fahren" hat ein sehr hohnen Preis, und seine Vorfächter scheinen, laut Forumsbeiträge in der Vergangenheit, darüber überhaubt nicht bewusst zu sein.

Deswegen begrüße ich dbts Vorschlag, um endlich diese destruktive Situation zu beenden. Ich finde den vorgeschlagenen Zeitpunkt durchaus realistisch.

Es konnte einfach ein Branch

Code: Alles auswählen

oldmake

angelegt werden (etwa wie jetztige newmake), newmake zu HEAD gemacht werden, und das letzte oldmake-als-head entsprechend ge-tagged werden. (Anlegen eines .../cdk/oldmake.files, auschecken mit

Code: Alles auswählen

 co -r oldmake cdk/oldmake.files; co -r oldmake 'cat cdk/oldmake.files`

etc).

Es muss auch absolut klar gemanchet werden, dass die Verantwortigung für die (eventuelle) Weiterpflege eines oldmake-Branch bei den "Oldmakern" liegen muss, sonst erreichen wir eigentlich nichts. Falls sie Hilfe anfordert, helfen wir. Falls sie nur nörgeln...

Zum Dreambox/Dreambox branch:

Es hat aber was, wenn man make flash-neutrino-dreambox700 oder so eingibt und hinten kommt ein Dreambox-Image raus. Und überhaupt dürfte die Frage nach Portierbarkeit auf andere Plattformen in Zukunft eine Rolle spielen.

Genau so soll das Ziel sein! Oder vielleich (eher) als z.B.

Code: Alles auswählen

.../configure --hosthardware=dreambox700 

. In jeden Fall gibt es ja das alte Zeugs (als Tag und/oder Branch). Der "oldmake"-Branch kann eigentlich sofort angelegt werden, so dass der Oldmake4ever-user schon testen kann. Again, die Verantwortigung muss bei den Intressenten liegen. Falls sie (oder einen andere Gruppe von Intressenten) nicht können oder nicht wollen, darf dadurch kein Druck auf das eigenständige Tuxbox-Projekt ausgeübt werden.

[seife]

Das mit der Dreambox ist nicht so anders, da dort halt doch komplett andere Versionen von libraries und tools benutzt werden. Ausserdem ist die Dreambox hier noch wesentlich toter als die dbox.

Insofern vermute ich mal, dass sich da niemand findet, der das macht. Ich lasse mich aber gerne eines besseren belehren.

[dbt]

Der "oldmake"-Branch kann eigentlich sofort angelegt werden, so dass der Oldmake4ever-user schon testen kann.

Würde ich auch meinen. Kannst ja schon mal anfangen. Wenn das läuft, könnte man erst mal ungestört weiter machen.
Und das:

Es muss auch absolut klar gemanchet werden, dass die Verantwortigung für die (eventuelle) Weiterpflege eines oldmake-Branch bei den "Oldmakern" liegen muss, sonst erreichen wir eigentlich nichts.

sollte ab dem Zeitpunkt, von dem an der Zweig existiert klar sein.

edit:
Hier mal eine Liste der Files, die für Oldmake markiert werden müssten. Kann das bitte mal jemand gegenchecken, damit da nix verhauen wird:

• apps/tuxbox/plugins/acinclude.m4
  apps/tuxbox/plugins/configure.ac
  apps/tuxbox/plugins/fx2/tetris/Makefile.am
  apps/tuxbox/plugins/Makefile.am
  apps/tuxbox/plugins/pluginx/.cvsignore
  apps/tuxbox/plugins/pluginx/Makefile.am
  apps/tuxbox/plugins/pluginx/pluginx.c
  apps/tuxbox/tools/configure.ac
  apps/tuxbox/tools/misc/Makefile.am
  
  boot/u-boot-config/u-boot.dbox2.h.m4
  
  cdk/acinclude.m4
  cdk/autogen.sh
  cdk/configure.ac
  cdk/Makefile.am
  
  cdk/doc/FAQ.en
  cdk/doc/INSTALL.en
  cdk/doc/README.3rdparty.de
  cdk/doc/README.3rdparty.en
  cdk/doc/README.flash.de
  cdk/doc/README.u-boot-via-net
  
  cdk/root/etc/init.d/Makefile.am
  cdk/root/etc/init.d/rcS.insmod
  cdk/root/etc/init.d/rcS
  
  cdk/root/etc/Makefile.am
  cdk/root/Makefile.inc
  cdk/root/share/udhcpc/Makefile.am

Für die Files unter apps/plugins und apps/tools müsst man mal schauen, ob man das irgendwie nach seifes Idee machen könnte, damit man die in jedem Branch verwenden kann.

[Barf]

Hier mal eine Liste der Files, die für Oldmake markiert werden müssten. Kann das bitte mal jemand gegenchecken, damit da nix verhauen wird:

apps/tuxbox/plugins/acinclude.m4
...

seht alles in Ordung aus. Leg los. Dazu kommt natürlich diverse redaktionelle Änderung in wiki, insbesonderes so dass Neueinsteiger (=! Anfänger!!) nicht auf die Idee kommen, oldmake zu benutzen ohne es WIRKLICH zu wollen.

Das mit der Dreambox ist nicht so anders, da dort halt doch komplett andere Versionen von libraries und tools benutzt werden. Ausserdem ist die Dreambox hier noch wesentlich toter als die dbox.

Insofern vermute ich mal, dass sich da niemand findet, der das macht. Ich lasse mich aber gerne eines besseren belehren.

Anderes ausgedrückt: Ich (und dbt) haben die Schwierigkeiten/der Aufwand unterschätzt. Kann gut stimmen, du hast wahrscheinlich recht. So basiert sich die Dreamboximagebau (laut mein Kenntnissstand) zum großen Teil aus closed-source binary-only Treibers etc. Schade

dbt: es gibt auch noch ein paar newmake-Dateien ausserhalb cdk/ (pluginx z.B.). Das war zwar eine löbliche Idee von Barf, das aufzuräumen, ich würde allerdings müssen wir da aufpassen, dass wir es nicht für die dreambox-Jünger kaputt machen, denn die nutzen ein oldmake-ähnliches Konstrukt zum Bauen, insofern sollte man da evtl. einfach die oldmake-Versionen benutzen.

Ich weiss nicht hier was du konkret vorschlägst. Oldmake zu verwänden in gesagte Directorybäume? Ich kann aus die Zeilen oben keine sachliche Kritik herleiten, nur "es ist anderes", und dies greift ja für das ganze Newmake thema. Die Wahrscheinlichkeit ist sicherlich höher dass man damit Newmake kaputtmacht, als z.B. die Dreamboxlern dir dankt. Man kan nicht einfach Teile austauschen, die nicht als austauschbar entworfen wurde. Falls du das Thema weiterführen will, bitte ich dich dein vorgeschlagene newmake + oldmake-für-tools-und-plugins vorzustellen und testen, sowie eine Begründung für die Vorteile deiner Lösung und der Nachteile von einer reine Newmake Lösung. Dein Vorschlag soll auch beschreiben wie die jetztige tools/plugins - newmake-Dateien zukünftig zu pflegen sind: neuer Branch newmake2?

Sicherlich gibt es Sachen die verbessert werden können; machen wir lieber dies (entweder du oder ich oder zusammen) als selbstvertrauenslos auf gewachsenes Müll zurückzufallen.

[seife]

dbt: es gibt auch noch ein paar newmake-Dateien ausserhalb cdk/ (pluginx z.B.). Das war zwar eine löbliche Idee von Barf, das aufzuräumen, ich würde allerdings müssen wir da aufpassen, dass wir es nicht für die dreambox-Jünger kaputt machen, denn die nutzen ein oldmake-ähnliches Konstrukt zum Bauen, insofern sollte man da evtl. einfach die oldmake-Versionen benutzen.

Ich weiss nicht hier was du konkret vorschlägst. Oldmake zu verwänden in gesagte Directorybäume?

Im prinzip ja. Unter anderem deswegen, weil "Dateien verschieben" in CVS extrem schmerzhaft ist (verlust der History etc).

Ich kann aus die Zeilen oben keine sachliche Kritik herleiten,

Das war keine Kritik und sollte auch keine sein, im Gegenteil. Ich kann durchaus verstehen, warum du pluginx nach plugins/ verschoben hast (und das ist ja praktisch die einzige Änderung ausserhalb cdk/, allerdings weiss ich nicht, ob dieses Cleanup den Aufwand rechtfertigt.

Andererseits: Ich mache die Umstellung nicht, und deswegen überlasse ich das euch, ihr kennt euch auch besser mit CVS aus als ich Wenn dabei für die dreambox etwas kaputt gehen sollte, dann werde ich das fixen (nicht umsonst habe ich meine DM500 wieder aus dem Schrott geholt)

Dein Vorschlag soll auch beschreiben wie die jetztige tools/plugins - newmake-Dateien zukünftig zu pflegen sind: neuer Branch newmake2?

Da hast du mich falsch verstanden. Mein Vorschlag war prinzipiell "verwendet in plugins/ einfach das oldmake-Makefile weiter", nicht "bitte 2 Branches in plugins/"

Sicherlich gibt es Sachen die verbessert werden können; machen wir lieber dies (entweder du oder ich oder zusammen) als selbstvertrauenslos auf gewachsenes Müll zurückzufallen.

Stimmt. Change is good, ich bin dabei

[dbt]

seht alles in Ordung aus. Leg los. Dazu kommt natürlich diverse redaktionelle Änderung in wiki, insbesonderes so dass Neueinsteiger (=! Anfänger!!) nicht auf die Idee kommen, oldmake zu benutzen ohne es WIRKLICH zu wollen.

Ok, wenn die ganzen Feiertagsbräten verdaut und andere "andere Nebenwirkungen" abgeklungen sind, mache ich das. Was die Änderungen im Wiki betrifft, versuche ich das sychron damit einher gehen zu lassen.

Ich für meinen Teil habe soweit erstmal alles Andere hinten rangestellt, weil doch Einiges hinterher nur funktioniert, wenn es auf Newmake basiert und ich auch nicht wirklich alles doppelt machen will.

Andererseits: Ich mache die Umstellung nicht, und deswegen überlasse ich das euch, ihr kennt euch auch besser mit CVS aus als ich Wenn dabei für die dreambox etwas kaputt gehen sollte, dann werde ich das fixen (nicht umsonst habe ich meine DM500 wieder aus dem Schrott geholt)

Mit cvs besser auskennen, puuh... sag das lieber nicht, aber dafür sollte es reichen und für die Sache mit der Dreambox hoffe ich, dass du das hinbekommst. Einen eigenen Dreambox-Branch durch Newmake überflüssig zu machen, wäre aber genial. Das wird aber wohl durch die verkrustete Oldmake-Basis wohl eher nicht von heute auf morgen passieren können. Ich kenne den Branch aber nicht so genau, so dass ich mir davon kein eindeutiges Bild machen kann, was da genau für eine Portierung auf Newmake gemacht werden muss.

Sicherlich gibt es Sachen die verbessert werden können; machen wir lieber dies (entweder du oder ich oder zusammen) als selbstvertrauenslos auf gewachsenes Müll zurückzufallen.

Also auf alten Kram, der nachweislich gewachsenes Müll ist, verzichtet man doch gern. Wenn es irgendwie geht, etwas besser zu machen, dann soll das auch so sein.

@Boardadmins: Es wäre evt. vorteilhaft, das Thema oben zu lassen.

[Barf]

Ok, Alles klingt gut. Zu Thema CVS: Wer hat eigentlich CVS adminrechte?

@seife: Ich habe pluginx nicht verschoben um meinen pedantischen Ordungssinn zu befriedigen, sondern um die Abhängigkeit von tools an plugins zu entfernen. Mit der Abhängigkeit war es nicht möglich, Makefile mit korrekte Abhängigkeiten zum laufen zu bekommen. Jedes Detail erinnere ich mich nicht, kann man aber sicherlich reproduzieren. Glaube mir, es war nicht leichtfertig, und falls mir eine einfachere Lösung mir dann bekannt wäre, hätte ich sie gewählt. In jeden fall wird dein Vorschlag (oldmake für plugins und tools) kaum funktionieren. Du machst einfach newmake damit kaputt.

Eine offensichtliche Alternative wäre einfach pluginx zu entfernen. Damit habe ich eigentlich keine Einwände

Falls du eine bessere Lösung (testbar!!) hast, bin ich offen für Alles. Es sollte jetzt klar sein, dass ich in kein Fall auf ein Verschiebung von pluginx festgelegt bin.

[dbt]

Oldmake-branch ist eingerichtet.
Auschecken:

anonym:

Code: Alles auswählen

cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r oldmake -P .

als CVS-User:

Code: Alles auswählen

echo "Checkout HEAD.."
CVSNAME="<username>"
echo "--------------------------------------------------------------"
cvs -z3 -d "$CVSNAME@cvs.tuxbox.org:/cvs/tuxbox" co -P .
echo "--------------------------------------------------------------"
echo "Checkout oldmake..."
echo "--------------------------------------------------------------"
cvs -z3 -d "$CVSNAME@cvs.tuxbox.org:/cvs/tuxbox" co -r oldmake -P cdk/oldmake.files
cvs -z3 -d "$CVSNAME@cvs.tuxbox.org:/cvs/tuxbox" co -r oldmake `cat cdk/oldmake.files`

Bin mir nicht 100% sicher, alles erwischt zu haben, aber das wird sich rausstellen wenn die newmake-Files in head sind. Jetzt bitte erst mal schauen ob der Checkout auch klappt. Im Wiki sind auch entsprechende Änderungen gemacht worden.

edit: -f Option entfernt

[Token]

@all:

zum thema dreambox:
das meiste image welches da genutzt wird ist das "gemini", waere es da
nicht sinnvoll sich an die jungs zu wenden?
die muessen ja auch ihr zeugs irgendwoher nehmen, und vorallen pflegen.
als frueherer dreambox-besitzer habe ich z.b. mit OE1.5/BB rumgespielt, da hat
"schaedelmeister" ein "make-script" dazu bereitgestellt.
damit konnte man sich sein eigenes image aus dem OE basteln, und war so
unabhaengig von Dream,Gemini,etc. - inwieweit aber da closed-treiber behandelt
werden - keine ahnung.
aber ich denke o.g. "schaedelmeister" koennte da bestimmt was zum thema sagen ?!

cu token

[seife]

Stellt einfach um, ich fixe dann die Dream-Ausfälle.

[dbt]

Stellt einfach um, ich fixe dann die Dream-Ausfälle.

Ein Mann ein Wort.
Als nächster Level kommen die selbständigen newmake files an die Reihe.

[Barf]

aber ich denke o.g. "schaedelmeister" koennte da bestimmt was zum thema sagen ?!

Die Registrierung ist offen... Falls er sich für das Tuxbox-projekt intressiert, liest er sicherlich mit...

[dbt]

Next Level:
Habe alles soweit gemerged. Eigentlich sollte es dann alles gewesen sein, bis auf die Dreamboxgeschichte, aber das kommt ja später.
Hier ein Diff der das komplette HEAD mit dem Newmake-Stand enthält. Ich bitte darum, das gegenzuchecken. Wenns lüppt, dann kommts rein:
tuxbox-cvs_newmake2HEAD-diff-2009-01-04-15-50-29.patch

[Barf]

als CVS-User:
Code:
echo "Checkout HEAD.."
CVSNAME="<username>"
echo "--------------------------------------------------------------"
cvs -z3 -d "$CVSNAME@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox" co -P .
echo "--------------------------------------------------------------"
echo "Checkout oldmake..."
echo "--------------------------------------------------------------"
cvs -z3 -d "$CVSNAME@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox" co -r oldmake -P cdk/oldmake.files
cvs -z3 -d "$CVSNAME@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox" co -f -r oldmake `cat cdk/oldmake.files`

Ohne "-f" in der letzte Zeile währe sicherlich besser, weil falls oldmake.files ein Fehler enthält soll der User lieber eine Fehlermeldung bekommen, als cvs leise von HEAD trunk sich bedient. Ausserdem wäre es sicherlich sinnvoll, Befehle wie

Code: Alles auswählen

rm -f ....rcS.m4
rm -rf cdk/make
rm -f apps/tuxbox/plugins/pluginx/pluginx.cpp

(zum Verwirrminimierung) in Beispiele zu schreiben.

Zum Thema pluginx:
Konkret schlage ich vor, wie im 7.4.1 in "The Cederqvist" zu verfahren: remove + add. Dadurch wird die History sich auf zwei Plätze sich verteilen. Andere Alternative sind in Cederqvist Kap 7.4 diskutiert. Dagegen spricht der Aufwand, dass (meines Wissens) niemand der z.Z aktive Devs admin-Rechte für CVS besitzt, und die relativ niedrige Wichtigkeit. In oldmake Branch wird sich pluginx.cpp auf altem Platz sich befinden.

Nein, dies stellt nicht eine elegante Lösung dar, was haptsächlich CVS-Mängel zuzuschreiben ist. Bessere (durchgedachte und durchführbare) Vorschläge sind willkommen.

Next Level:
Habe alles soweit gemerged. Eigentlich sollte es dann alles gewesen sein, bis auf die Dreamboxgeschichte, aber das kommt ja später.
Hier ein Diff der das komplette HEAD mit dem Newmake-Stand enthält. Ich bitte darum, das gegenzuchecken. Wenns lüppt, dann kommts rein:
tuxbox-cvs_newmake2HEAD-diff-2009-01-04-15-50-29.patch

Hmm, ein Patch, dass jetzige HEAD in newmake umwandelt? Gibt es andere Änderungen, bitte verbal beschreiben. Bin mir nicht sicher, was du mit "gegenzuchecken" meinst.

Hier ist meine Version des TODOs (vgl Cederqvist, kap 5.6):

• Neutrino Iconfiles löschen vom newmake Branch, newmake.files anzupassen, siehe http://tuxbox-forum.dreambox-fan.de/for ... =7&t=45375
• HEAD auszuchecken
• Stand tag-gen, z.B. als last_oldmake_head
• working copy fixen, z.B. mittels -j option zu update.
• files wie rcS, rcS.insmod, pluginx.cpp (in altem Location) removen (sind ja schon in oldmake branch vorhanden)
• files wie rcS.m4, pluginx.cpp add-en
• committen
• wiki updaten

Zukünftig wird dann der newmake branch bestehen, sollte aber normalerweise nicht zum einchecken benutzt werden.

[dbt]

Bin mir nicht sicher, was du mit "gegenzuchecken" meinst.

Einfach, ob alles komplett ist. Habe aber inzwischen gesehen, dass noch newmake.files und rcS und rcS.insmod drin sind. die Sachen müssten eigentlich noch raus.

Wieso ich da einen Patch angebe, ganz einfach: Der ensteht nunmal nach der ganzen Prozedur. Ich bin da im Prinzip nur so vorgegangen, wie es mir am sinnvollsten erscheint und in etwa auch so wie du es vorschlägst und mir gehts auch darum, dass auch die Konflikte sauber gelöst sind, also dass ich nichts übersehen habe, sonst gibts hinterher Ärger:

• updaten/HEAD auschecken
  diffen von HEAD newmake
  updaten/mergen
  Konflikte auflösen (davon gabs reichlich )
  
  Patch erstellt (der steht jetzt zur Prüfung)
  
  newmake.files (übrig)
  rcS (übrig)
  rcS.insmod (übrig)
  commit ist übrig
  Wiki/Dokus ändern (übrig)

Ich schau mir das aber noch mal an.

Zukünftig wird dann der newmake branch bestehen, sollte aber normalerweise nicht zum einchecken benutzt werden.

Bin mir nicht sicher, aber wäre es nicht besser, den Branch dann zu entfernen, nur um keine Verwirrung zu stiften. Ich kann mir dann gut vorstellen, das das nicht gut geht, zumindest eine bestimmte Zeit. Beim Abrufen der Branches sind mir noch einige ältere Branches entgegengekommen, von denen nur noch der Name existiert. Ich würde es damit genauso halten.

PS: CVS-Adminrechte müsste zumindest derget haben, wird aber kaum damit was zu tun haben (wollen)...

[dbt]

Im großen und ganzen mach ich das mal so und wenn alles so funktioniert wird der Termin etwas früher liegen:

* Neutrino Iconfiles löschen vom newmake Branch, newmake.files anzupassen, siehe http://forum.tuxbox-cvs.sourceforge.net ... =7&t=45375
* HEAD auszuchecken
* Stand tag-gen, z.B. als last_oldmake_head
* working copy fixen, z.B. mittels -j option zu update.
* files wie rcS, rcS.insmod, pluginx.cpp (in altem Location) removen (sind ja schon in oldmake branch vorhanden)
* files wie rcS.m4, pluginx.cpp add-en
* committen
* wiki updaten

* Neutrino Iconfiles löschen vom newmake Branch, newmake.files anzupassen, siehe http://forum.tuxbox-cvs.sourceforge.net ... =7&t=45375

Das wollte ich schon damals machen, nur die Files sind (versehentlich) mit newmake markiert und habe die damals nur als Kompromiss reingenommen, weils nach dieser Methode lt. DietmarW

Code: Alles auswählen

cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r newmake -P .

in die Hose ging. Die Files wurden dann immer noch gezogen, allerdings wegen des Tags kam nix mehr, weil die ja dort removed waren.
Meinst du mit "Tag entfernen" gehts?

Code: Alles auswählen

cvs tag -d newmake "blau.raw" "gelb.raw" "gruen.raw" "rot.raw" 

Hatte ich versucht, ging aber nicht

Code: Alles auswählen

cvs tag: Not removing branch tag `newmake' from `/cvs/tuxbox/apps/tuxbox/neutrino/data/icons/blau.raw,v'.
cvs tag: Not removing branch tag `newmake' from `/cvs/tuxbox/apps/tuxbox/neutrino/data/icons/gelb.raw,v'.
cvs tag: Not removing branch tag `newmake' from `/cvs/tuxbox/apps/tuxbox/neutrino/data/icons/gruen.raw,v'.
cvs tag: Not removing branch tag `newmake' from `/cvs/tuxbox/apps/tuxbox/neutrino/data/icons/rot.raw,v'.

Irgendein Tipp?
Und klar, mit Anbindung an newmake.files, gehts ohne Probleme.

Code: Alles auswählen

cvs -z3 -d "user@cvs.tuxbox.org:/cvs/tuxbox" co -f -r newmake `cat cdk/newmake.files`

Das wird teilweise auch beim yBulid so benutzt, aber meines Wissens nach nicht für anoncvs sondern nur mit user
Das gute CVS ist immer wieder für Überraschungen gut, solange man die Logik, die dahinter steckt, nicht genau nachvollzieht.

[Barf]

Code:
cvs tag -d newmake "blau.raw" "gelb.raw" "gruen.raw" "rot.raw"

Hatte ich versucht, ging aber nicht

Hast -B vergessen; sonst versucht das tag-Kommando ein normale Tag, nicht ein Branchtag zu entfernen.

Ich habe gerade die vier Dateien von newmake entfernt, und zwar wie in seifes anleitung.
Dazu newmake.files aktualisiert.

Sonst seht ja alles gut aus!

[dbt]

* Stand tag-gen, z.B. als last_oldmake_head

Du meinst damit den kompletten Tree? Nur Tag, kein Branch?

[Barf]

Du meinst damit den kompletten Tree? Nur Tag, kein Branch?

Yup. So kann man auschecken mit z.B.

Code: Alles auswählen

cvs co -r last_day_of_the_dark_ages -dP .

etwa synonym mit auschecken mit einem besonderen Datum (-D 2009-01-12). Siehe Cederqvist Kap 4.

Tagging sind nicht viel in diesem Projekt benutzt, aber das Projekt ist auch nicht sonderlich vorbildlich wenn es um Administration und Verwaltung geht...

Bin mir nicht sicher, aber wäre es nicht besser, den Branch dann zu entfernen, nur um keine Verwirrung zu stiften.

Erstmals wurde es 3 Jahren History vernichten, besonders für wirklich parallel entwickeltes Zeug wie cdk/configure.ac. Zweitens wird es generell abgeraten in den CVS-Guides, Branches zu entfernen. Was man vielleicht machen möchte, wäre den Branch readonly zu machen. Weil CVS nicht Konfigurationen, Tags etc als versionierbare Objekte behandelt, geht dies (meines Wissens) nicht. CVS geht mir mehr und mehr auf den Keks...

[dbt]

Tagging sind nicht viel in diesem Projekt benutzt, aber das Projekt ist auch nicht sonderlich vorbildlich wenn es um Administration und Verwaltung geht... ...
CVS geht mir mehr und mehr auf den Keks... ...

Kann man nachvollziehen, je mehr man sich dem annimmt. Habe auch jede Menge (toter) Tags/Branches gefunden, die scheinbar gewisse Ansätze vom Namen her haben, die auf Versuche hinweisen, dies vernünftig zu machen, aber davon ist nicht mehr viel übrig. Ich nehme an die Wartung solcher Dinge ist auch mit einem gewissen Aufwand verbunden, dem sich keiner so recht gestellt hat, zumindest hat keiner die Verantwortung dafür übernommen. Ist halt eine Frage von Aufwand und Nutzen.

Bin mir nicht sicher, aber wäre es nicht besser, den Branch dann zu entfernen, nur um keine Verwirrung zu stiften.

Erstmals wurde es 3 Jahren History vernichten, besonders für wirklich parallel entwickeltes Zeug wie cdk/configure.ac. Zweitens wird es generell abgeraten in den CVS-Guides, Branches zu entfernen. Was man vielleicht machen möchte, wäre den Branch readonly zu machen. Weil CVS nicht Konfigurationen, Tags etc als versionierbare Objekte behandelt, geht dies (meines Wissens) nicht. CVS geht mir mehr und mehr auf den Keks...

Ok, leuchtet ein.

[Striper]

Naja, es sind schon größere Projekte als das hier auf SVN umgestellt worden. Und wer einmal eine Zeit lang mit SVN arbeiten durfte weiß was ich meine.

Jetzt dürft ihr mich wieder flamen.

Problem ist jedoch wohl hier das die aktiven Entwickler keinerlei Administrative Tätigkeiten auf dem Server ausführen können...

[dbt]

Jetzt dürft ihr mich wieder flamen.

Auch SVN hat auch seine Tücken und so problematisch ist das hier auch wieder nicht.

Zum Thema:
So wie ich das sehe, hab ich den Kram soweit, wenn es keine Bedenken gibt, wird dann umgestellt.

[seife]

Wenn man heute noch irgendwohin umsteigt, dann auf git