hijacked File updaten

[Günther]

Welchen Befehl muß ich den verwenden, um ein einzelnes hijacked File auf den neusten Stand zu bringen. Wenn ich das cdk update wird ja normalerweise ein merge gemacht (will ich aber in diesem Fall nicht, die Änderungen können überschreiben werden). Und wie kann man alle hijacked Files mit der neusten Version überschreiben?

Gibt es denn irgendwo eine kleine verständliche Beschreibung (am besten Beispiele) über die wichtigsten cvs Befehle?

Günther

[Barf]

Hallo Günter,

Für CVS Doku: http://ximbiot.com/cvs/manual/, insbesonderes "The Cederqvist".

Sonst mache ich sowas wie

Code: Alles auswählen

mkdir fummel
mv *.cpp fummel
cvs up

cvs status ist auch oft nützlich.

[Günther]

ok, danke,

... und wenn ich jetzt das ganze project updaten will, was soll ich dann am besten machen:
/tuxbox-cvs$ export CVS_RSH=ssh
/tuxbox-cvs$ cvs -d:pserver:anonymous@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox -z3 up -dP

und

/tuxbox-cvs/cdk$ ./autogen.sh
/tuxbox-cvs/cdk$ ./configure --enable-maintainer-mode \
--prefix=$HOME/dbox2 \
--with-cvsdir=$HOME/tuxbox-cvs

und
/tuxbox-cvs/cdk$ make all

????

Frage deswegen, weil ich das gerade gemacht habe und mir mein Festplattenspeicher aus ging (irgendwie wurden mal so eben 2 GB neue Daten erstellt). Muss ich vorher irgendwelche Daten löschen. Der cdk und dbox Ordner sind jetzt über 4GB groß ????

Habe gerade verzweifelt alle möglichen Linuxkomponenten deinstalliert (Meine Partition ist 'nur' 7GB gross) aber irgendwie hat es nichts geholfen ...

[Npq]

Das Größte ist der glibc-build, dieser belegt am Ende (bevor das Verzeichnis wieder gelöscht wird) etwas über ein GiByte an Platz. Der muß dann natürlich vorhanden sein.

Beim Projekt updaten ist es eigentlich nur sehr selten nötig, alles neu zu bauen (höchstens wenn wie neulich gcc und glibc upgedated werden ist das zu empfehlen).

In den jeweiligen Unterverzeichnissen ein "make clean" oder "make distclean" (je nach Bedarf).

Man sollte sich am besten die binutils in den Pfad legen, so daß man auch in den Unterverzeichnissen bauen kann ohne das Haupt-Makefile zu verwenden.

[Houdini]

wenn du die targetrulesetflash aktivierst wird auch alles ohne debug infos kompiliert, was einiges an Platz bringt, musst dann halt einiges fürt ein NFS run ändern. (kernelconfig, busyboxconfig)

[Günther]

@Npq
Mein letzter Snapshot war vom 11.9.2005. Habe ich gestern im neutrino ordner nur mit 'cvs up' geuppt (nachdem ich mein dbox/tuxboc-cvs Sicherungszip vom 11.9. drübergebügelt habe). Klappt das dann mit den gcc. Und wenn nicht, was müßte ich noch machen (image ist jedenfalls gelaufen )

Kannst Du das mit den binutils nochmal detailieren ?

Was mich gestern nur gewundert hat, vor dem Update waren es zusammen 2 GB (dbox,tuxbox-cvs) , während und nach dem Update/make all sind dann nochmal 2GB dazugekommen (bis die Meldung 'kein Speicherplatz' kahm ) Das sah mir eher nach einer Neuinstallation aus

@Houdini
NFS run ändern. (kernelconfig, busyboxconfig) Hört sich ja interessant an, überfordert mich jetzt aber gerade mit meinen frischen Linuxkenntnissen.
Welche Debug infos meinst Du denn, die RS232-Ausgabe oder für den Debugger. Gibts sowas für dbox, ich debugge gerade nur mit Textausgabe und bei Bedarf mit VC++ (kenn mich leider mit linux noch zu wenig aus, um das zu ändern bin ich aber auch hier )

[Npq]

Gcc und glibc wurden vor 2 Wochen upgedated, die glibc nochmal vor 3 Tagen.

Die Logik ist die, daß alle Pakete, die in "Archive" liegen nach und nach im CDK-Verzeichnis entpackt, gebaut und in das Prefix-Verzeichnis installiert werden. Anschließend werden die build-Verzeichnisse wieder gelöscht.

Binutils war nicht ganz korrekt, ich meinte eigentlich alles was im cdk/bin-Verzeichnis im Prefix-Verzeichnis liegt.

Da bei gcc und Co immer das powerpc-tuxbox-linux-gnu vorne steht passiert nichts, wenn man das Verzeichnis in den Pfad legt. Vorteil ist halt, daß man die generierten Makefiles dann direkt ausführen kann.

Ich hab dafür einfach einen eigenen Benutzer, bei dem der Pfad im profile eingetragen ist.

Also VC.NET benutze ich auch ständig, aber bislang noch nicht auf der Box.

Da kann man gdb-remote verwenden (gdb selber läuft zwar auch, aber dafür ist zu wenig Speicher vorhanden).

Obi hatte dafür mal eine Anleitung hier im Forum gepostet. Im Grunde startet man den gdb auf dem PC und dieser verbindet sich dann mit einem Stub-gdb auf der Box, so daß man ferndebuggen kann.

Ist aber nicht mit der Komfortabilität des WinDbg zu vergleichen. :-/