CVS Down

[derget]

Sorry das CVS ist erstmal bis auf weiteres down.

Ich weiss nicht wann ich dazukomme die Mühle neu aufzusetzten.

Ein letzten Export/Backup kann ich gerne machen wenn bedarf besteht.

Grüße

Derget

[dbt]

Schiebs doch einfach auf einen Sourechoster hoch. Gibt ja genug. Git war ja schon mal im Gespräch. Ist ja damals eigentlich eindeutig ausgefallen. Ich hab das dieses Wochenende sogar komplett gezogen und nach git exportiert. Das wäre so gesehen, kein Akt und innherhalb von ein paar Stunden, wenn überhaupt soviel, erledigt. Musst nur sagen wohin. Aber das liegt ganz bei Dir.

[dwilx]

Sorry das CVS ist erstmal bis auf weiteres down.

Ich weiss nicht wann ich dazukomme die Mühle neu aufzusetzten.

Ein letzten Export/Backup kann ich gerne machen wenn bedarf besteht.

Grüße

Derget

Ui, das hört sich aber längerfristig an, und "bis auf Weiteres" hat in manch anderem Kontext schon das Ende bedeutet.

[dietmarw]

auch wenn ich git eigentlich nicht mag (weil es bei mir zu oft einfach die verbindung beendet)..

evtl. sollte man den umstand dazu nutzen die alten "cvs zöpfe" wirklich mal abzuschneiden?

[dwilx]

auch wenn ich git eigentlich nicht mag (weil es bei mir zu oft einfach die verbindung beendet)

Versteh ich gerade nicht? Bei git bist du doch nicht auf den Server angewiesen, ist doch verteilt!

[dbt]

...evtl. sollte man den umstand dazu nutzen die alten "cvs zöpfe" wirklich mal abzuschneiden...

Denke ich auch, wenn nicht git, dann zumindest svn, aber das wäre dann inkonsequent (...und git macht eigentlich mehr Laune). Wie gesagt, ich habe den letzten Stand am Wochenende komplett als 5 Repos parat liegen (blöder Zufall, aber nur weil ich das Tuxbox-CDK neu einrichten musste). Für den Rest brauchts nur 'nen Hoster, derget,s OK und dann wäre das kein Akt mehr.

[derget]

So, also ich kann das CVS schon neu aufsetzten.
Weiss nur noch nicht wann ich das machen kann.

Die Frage ist für mich eher: Braucht das denn wirklich noch wer ?

[rhabarber1848]

Wenn eine Portierung des CVS nach git mit allen branches und der kompletten
commit-history aller branches möglich ist, wäre git ein vollwertiger Ersatz.

[dbt]

Die Frage ist für mich eher: Braucht das denn wirklich noch wer ?

Die Sourcen schon, damit wird ja wie gehabt hantiert, nur CVS an sich ist halt etwas überholt. Es wurde ja schon länger darüber abgestimmt und CVS hatte demnach ausgedient. Die Umsetztung ist aber dann eingeschlafen.

Wenn eine Portierung des CVS nach git mit allen branches und der kompletten
commit-history aller branches möglich ist, wäre git ein vollwertiger Ersatz.

Natürlich geht das einschl. Branches und Tags. Du kannst das ganze Chaos übernehmen. Allerdings wie bereits erwähnt, die 5 Module wären dann in jeweils ein Repo aufgeteilt. Man könnte das sicher sinnvoll aufdröseln, aber das wäre mal 'ne Aufgabe wo ich mich jetzt nicht reindenken mag. Sowie man aber mit Git zu tun hat, dürfte aber klar werden, was man da machen könnte. Frage ist halt, ob das dann zwingend notwendig wäre und sich das jemand antun will.

[rhabarber1848]

die 5 Module wären dann in jeweils ein Repo aufgeteilt.

Was ist der Grund dafür?

Man könnte das sicher sinnvoll aufdröseln, aber das wäre mal 'ne Aufgabe wo ich mich jetzt nicht reindenken mag.

Noch mehr Einzelmodule oder weniger als die jetzigen fünf?

Sowie man aber mit Git zu tun hat, dürfte aber klar werden, was man da machen könnte.

Mangels Erfahrung mit git kann ich derzeit dazu nichts beitragen.

[doc]

die 5 Module wären dann in jeweils ein Repo aufgeteilt.

Was ist der Grund dafür?

Nun, schlichtweg die sinnvolle Aufspaltung in logische Einheiten. Das macht es externen Buildsystemen wesentlich einfacher nur die Sachen zu pullen die wirklich benötigt werden. Wenn Du möchtest, oder eben per Buildsystem kann man das lokal per Git wieder mittels Submodule genau so zusammen setzen wie Du oder die meisten es kennen.

Man könnte das sicher sinnvoll aufdröseln, aber das wäre mal 'ne Aufgabe wo ich mich jetzt nicht reindenken mag.

Auf Dauer würde das Sinn machen, man muss ja nichts überstürzen. Aus historischer Sicht würde ich die einzelnen Branches schon erhalten, im Git benutzt das nicht sonderlich viel Platz. Auch wenn die Jahre alten Dinger heute natürlich keine Rolle mehr spielen. Über eine Struktur kann man ja reden.

Sowie man aber mit Git zu tun hat, dürfte aber klar werden, was man da machen könnte.

Mangels Erfahrung mit git kann ich derzeit dazu nichts beitragen.

Da hat dbt ganz klar Recht, man sieht plötzlich ganz neue Möglichkeiten.

[dbt]

die 5 Module wären dann in jeweils ein Repo aufgeteilt.

Was ist der Grund dafür?

Ist ein Kompromis...

Man könnte das sicher sinnvoll aufdröseln, aber das wäre mal 'ne Aufgabe wo ich mich jetzt nicht reindenken mag.

Noch mehr Einzelmodule oder weniger als die jetzigen fünf?

...weil man das eigentlich noch mehr aufteilen müsste, da es wenn man es genau nimmt, etliche Unterprojekte geben müsste, aber wie gesagt, das ist ein Kompromis. z.B.: Ein Problem im CVS, ist halt das starre Gebilde, eine Revision, Branch oder Tag zieht sich über alles, auch da wo mal was gar nix mit zu tun hat. Da fährt Git ganz andere Geschütze auf. Sollte natürlich ein Experte die Muse dazu haben, sich da mal dran zu machen, wenn es sich lohnt, super.

Sowie man aber mit Git zu tun hat, dürfte aber klar werden, was man da machen könnte.

Mangels Erfahrung mit git kann ich derzeit dazu nichts beitragen.

Das würde sich von selbst ergeben. Aber noch ist ja nix amtlich.

Edit: Doc war schneller.

[dwilx]

push!
Gibts was neues, so ganz ohne ist es nicht gerade fruchtend!

[dbt]

Gitrepos mit alle bisherigen Tags und Branches sind bei Sourceforge vorbereitet, auch einige Schreibberechtigungen für die bereits bekannten CVS-Schreibberechtigten und einen SF-Account haben, sind verteilt, auch für derget, nur fehlt noch ein Feedback von ihm, ansonsten gehts halt nicht public.

[doc]

Was spricht den gegen einen RO Zugriff bis das mit dem CVS geklärt ist? So könnte der jeder der in der Zwischenzeit am Code arbeiten will weiter machen und fertige Gitpatches erstellen. Und gerade auf des eine zentralere Git Repo müsste nicht jeder Schreibzugriff haben. Am sonst in der Welt üblichen Workflow per ML hat sich immer noch nichts geändert.

Aber ich denke auf längere Sicht wird man um Git oder eine Alternative dazu nicht herum kommen. Ich denke mal das derget nichts gegen einen Umzug auf ein anderes Versionsverwaltungssystem einzuwenden hat. Und Plattformen wir Sorceforge, Github oder Gitorious sind mit Sicherheit nicht falsch.

[dbt]

Was spricht den gegen einen RO Zugriff bis das mit dem CVS geklärt ist? So könnte der jeder der in der Zwischenzeit am Code arbeiten will weiter machen und fertige Gitpatches erstellen. Und gerade auf des eine zentralere Git Repo müsste nicht jeder Schreibzugriff haben. Am sonst in der Welt üblichen Workflow per ML hat sich immer noch nichts geändert.

Vorgreifen ist zwar nicht so fein, aber da ist was dran und auf Dauer ist es so im Moment eigentlich nicht wirklich fein, also ok.
Hier gehts zur Übersicht:

Hier ein kleines Script, um alles wie gehabt auf seine Maschine zu bekommen. Alles erst mal RO. Ausser Sandbox, zum spielen

Code: Alles auswählen

#!/bin/sh

REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

oder auch per http:

Code: Alles auswählen

REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone http://git.code.sf.net/p/tuxbox-cvs/$f $f
done

Patche erstellen: How_to_become_a_Developer#Patch_erstellen

[dietmarw]

in "apps boot driver hostapps" ist ja dann auch der erwartete inhalt.
"cdk" hingegen ist leer..

[dbt]

...
"cdk" hingegen ist leer..

Kann ich nicht bestätigen, alles randvoll:

Code: Alles auswählen

dbt@linux-11-3:~/tmp/test> REPLIST="apps boot cdk driver hostapps sandbox"
dbt@linux-11-3:~/tmp/test> for f in  $REPLIST ; do
>    git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
> done
Klone nach 'apps'...
remote: Counting objects: 130540, done.
remote: Compressing objects: 100% (26048/26048), done.
remote: Total 130540 (delta 104238), reused 129748 (delta 103446)
Receiving objects: 100% (130540/130540), 36.71 MiB | 337 KiB/s, done.
Resolving deltas: 100% (104238/104238), done.
Klone nach 'boot'...
remote: Counting objects: 5372, done.
remote: Compressing objects: 100% (2448/2448), done.
remote: Total 5372 (delta 2926), reused 5240 (delta 2794)
Receiving objects: 100% (5372/5372), 5.63 MiB | 348 KiB/s, done.
Resolving deltas: 100% (2926/2926), done.
Klone nach 'cdk'...
remote: Counting objects: 14066, done.
remote: Compressing objects: 100% (3887/3887), done.
remote: Total 14066 (delta 10134), reused 13921 (delta 9989)
Receiving objects: 100% (14066/14066), 5.12 MiB | 444 KiB/s, done.
Resolving deltas: 100% (10134/10134), done.
Klone nach 'driver'...
remote: Counting objects: 16573, done.
remote: Compressing objects: 100% (4926/4926), done.
remote: Total 16573 (delta 10360), reused 16323 (delta 10110)
Receiving objects: 100% (16573/16573), 3.29 MiB | 444 KiB/s, done.
Resolving deltas: 100% (10360/10360), done.
Klone nach 'hostapps'...
remote: Counting objects: 2604, done.
remote: Compressing objects: 100% (1014/1014), done.
remote: Total 2604 (delta 1467), reused 2604 (delta 1467)
Receiving objects: 100% (2604/2604), 6.35 MiB | 447 KiB/s, done.
Resolving deltas: 100% (1467/1467), done.
Klone nach 'sandbox'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
dbt@linux-11-3:~/tmp/test> 
dbt@linux-11-3:~/tmp/test> cd cdk
dbt@linux-11-3:~/tmp/test/cdk> ls
acinclude.m4  autogen.sh  common-licenses  configure.ac   doc   Makefile.am  Patches  prepare_dream  root        rules-archive     rules-downcheck.pl.in  rules-make
AUTHORS       ChangeLog   config           customization  make  NEWS         prepare  README         root_dream  rules-archive.pl  rules-install          rules.pl
dbt@linux-11-3:~/tmp/test/cdk> 

[doc]

dito

Code: Alles auswählen

carsten@build01:~/gitprojects$ du -h --max-depth=1 cdk/
72K     cdk/doc
5,7M    cdk/.git
424K    cdk/root
16K     cdk/customization
204K    cdk/config
544K    cdk/root_dream
3,0M    cdk/Patches
412K    cdk/make
72K     cdk/common-licenses
11M     cdk/

[dietmarw]

fehler gefunden..

das verzeichnis cdk existierte vor dem checkout schon mit einer datei darin.
dann bricht das git clone den zweig ab.

[dbt]

OK. Hätte mich auch gewundert.
Bleibt trotzdem die Frage, ob man das jetzt so umstellen kann. Derget hat sich ja bisher noch nicht geäußert. Entscheidungen vorwegzunehmen, kommt nicht so gut, allein schon deswegen, weil er das jahrelang zuverlässig gemacht hat. Das ist hoch anzurechnen und ein einfaches Danke reicht wahrscheinlich nicht. Andererseits ist eine dauerhafte Übergangslösung auch kein Zustand.

[svenhoefer]

dbt, könntest du noch ein superproject drumrum bauen, um ein rekursives auschecken zu ermöglichen? da das eine ja nicht ohne das andere funktioniert, bietet sich das meiner meining nach hier an.

ein "git clone --recursive $(TUXBOX_GIT) tuxbox" sieht dann auch schöner aus, als die for-schleife.

[dbt]

Sicher,aber solange das noch nicht offiziell ist, macht das noch nicht wirklich Sinn, gewisse Details auszubilden. Ausserdem bin ich mir auch nicht 100% sicher, ob man die Aufteilung so lässt oder ob man noch mehr zerlegt, um etwas mehr Struktur drin zu haben.

[derget]

Moin moin,

sorry, meine Inbox im Forum war wohl schon vor ein paar Monaten übergelaufen, daher hab ich die neuen Nachrichten nicht gesehen.

Ihr habt mein Ok, das cvs umzuziehen.

Wenn ihr dafür noch was benötigt, ich tar gz mal den letzten cvs stand und pack ihn wo hin.

Grüße

derget

[derget]

So hier der letzte stand vom CVS.
Für Nostalgiker und portierer :)

http://cvs.tuxbox-cvs.sourceforge.net/t ... 12.tar.bz2