Ok... Danke...
Hab jetzt mal auf der Box ein BDB-Repository auf 'nem Stick erstellt, ausgecheckt und 'ne neue Datei commitet. Dann den Stick abgezogen, im PC eingesteckt und versucht von da auszuchecken:
Berkeley DB error for filesystem <REPOPFAD> while opening environment: Not enough space bdb: unable to allocate memory for mutex;resize mutex region
Auf dem Stick sind >400MB frei... Auf die Platte kopiert kommt der gleiche Fehler.
Laut Quelltext wird dieser Fehler aber nicht zwangsläufig von mangelndem Speicherplatz verursacht, sondern generell, wenn der Mutex nicht erzeugt werden kann ("MUTEX_INVALID").
=== kurzer Test ===
Hab grad mal versucht mein Repository (bisher 103 Revisionen, 29MB groß) per Dump/Load vom PC auf die Box (Speicherort ist Stick) zu bekommen... geht ziemlich langsam, aber das war ja zu erwarten. Aber bei Import von Revision 65 hängt er und laut "free" sind nur noch 392kB RAM frei. Ich lass ihn mal etwas weiter hängen...
//eine Weile später...
Grad eben hab ich gesehn, dass er wieder weiterläuft. Rev 69 und 772kB frei. Hmm... Ich lass ihn mal weiterlaufen.
//eine Weile später...
Nach ziemlich langer Zeit (so ca. 3h) ist es vollständig auf der Box. An RAM sind jetzt noch 2MB frei.
Ein Checkout des Trunks auf meinen PC per WLAN dauert ca. 4 Minuten (lokal per svnserve von PC-HDD ca. 30sec), dabei schwankt der freie RAM der Box zwischen 1MB und 520kB.
Nach dem Checkout sind 7MB RAM auf der Box frei.
Die im Repository enthaltenen Binaries sind alle korrekt übertragen wurden.
Ich werde später mal sehen, ob der wenige freie Speicher beim Auschecken beim Telefonieren über die Box ein Problem wird. Sollte das klappen, kann man das wohl auf der Box so einsetzen. Checkout und vermutlich auch Update ist zwar deutlich langsamer, aber immernoch in einem Rahmen, mit dem man leben kann.
Also gute Arbeit, Luemmel! Vielen Dank dafür.
Trotzdem wäre ich dankbar für ein kurzes HowTo, wie ich das hier mal selbst kompiliert bekomme...