Subversion auf Fritzbox

[HAL 9000]

Ich hab mich mal aus Eigenbedarf dran versucht. Rausgekommen sind statische Binaries von svnadmin und svnserve. Auf den ersten Blick scheinen sie zu laufen, allerdings hatte ich noch keine Gelegenheit das ganze ausführlich zu testen, da ich im Moment nur an eine FBF 7050 herankomme und die natürlich nicht genug Speicher für ein Repository realistischer Größe hat. Die Binaries unterstützen außerdem nur FSFS-Repositories, kein BerkeleyDB.
Du kannst sie ja mal ausprobieren. Irgendwann werd ich auf jeden Fall auch noch daran weiterbasteln.

 

[SvenFranz]

Hi HAL
Super, vielen Dank!
wird gleich getestet!!!
Gruß
Sven
P.S. bin zwar gerade dabei und versuche mich (zum ersten mal) selbst daran, für die FB zu kompilieren... aber bis ich soweit bin...

 

[SvenFranz]

Hi HAL,
erhalte beim testen (auf fat32-USB-Stick) die bereits bekannte Fehlermeldung "malformed text rep offset line in node-rev"... Ist es bei Dir auch so?

Gruß
Sven

P.S. habe diesbezüglich diesen Eintrag gefunden:
http://forum.opennas.info/viewtopic.php?p=9339&sid=775c41c1856e0998dc69eb68cab7c897
vielleicht hilft es!?!?

 

[HAL 9000]

Ja ich krieg das gleiche. Verdammt Der Post den du Verlinkt hast könnte helfen, die ersten vier der aufgelisteten Parameter habe ich schon benutzt weils sonst gar nicht compilieren wollte Ich probier nochmal rum...

Edit: Mit der Version im Anhang konnte ich erfolgreich kleinere Dateien commiten. Größere kann ich wie gesagt nicht ausprobieren wegen Speichermangels. Im Anhang sind wieder beide Dateien drin, allerdings hat sich nur svnserve geändert.

 

[SvenFranz]

Erster Test: es läuft auch bei mir...
größte getestete Datei: ein eps mit 1,4MB!
(allerdings Absturz bei einer PDF mit 1,5MB...)

Soweit sieht es schon sehr gut aus... teste morgen weiter!

Gruß
Sven

 

[olistudent]

War da vielleicht das RAM voll? Probier doch mal auf dem Stick eine Swap-Datei einzurichten.

MfG Oliver

 

[SvenFranz]

Hi Oliver
gerne... aber: noch nie gemacht.... hast du da nen Tip?
Gruß
Sven

 

[SvenFranz]

Alles klar... swap ist eingerichtet (http://www.ip-phone-forum.de/showthread.php?t=136175&highlight=mkswap+swapon)... nun teste ich weiter!
Gruß
Sven

 

[SvenFranz]

Zwischenbericht:
Nutze SVN ohne ds-mod o.ä., nur mir Anpassungen per config.cfg
free ergibt folgendes:

              total         used         free       shared      buffers
  Mem:        30280        27096         3184            0         1116
 Swap:        65528            0        65528
Total:        95808        27096        68712

SVN läuft (im lokalen Netzwerk) sehr langsam...
ich verwende Windows mit Tortoise SVN. Wenn ich eine eingechecktes Repository (Gesamtgröße: 65kB) über den Repository-Browser betrachten will, dauer es teilweise einige Minuten, bis der Inhalt eines Verzeichnisses (nur wenige Dateien (<5)) angezeigt wird...

Welche Möglichkeiten habe ich, um zu schauen, was die FB währendessen anstellt?

Gruß
Sven

 

[HAL 9000]

Konnte ich bisher nicht nachvollziehen... ein Testrepository mit 45 Dateien und 65kb kann ich mit TortoiseSVN beliebig schnell betrachten, ein- und auschecken. Während eines Checkin/out lastet svnserve die cpu allerdings total aus. Ich werde bei Gelegenheit auch mal einzelne größere Dateien ausprobieren.

Edit: Inzwischen bin ich bei knapp 400kb. Ich habe dein Eindruck, dass der Repo-Browser etwas langsamer wird, aber noch befinde ich mich im Bereich 1-2 Sekunden. Bei welcher Revision ist dein Repository denn, und was für eine Box hast du?

 

[SvenFranz]

Habe eine 7170!
Das Komische ist, dass es gestern echt flott war... habe heute morge dann das Repository gelöscht und neu angelegt... seit dem habe ich die Probleme...
Revision steht aktuell auf 4...

Was hast Du in den authz, passwd und svnserv.conf stehen?
Habe pro Client-Zugriff einen neuen Eintrag in der Prozessliste (ps)... ist das normal?

Es kommt sogar vor, dass es gar nicht weitergeht... der Repository-Browser steht nun seit ca 1 Stunde... Cursor ist ne Sanduhr...

 

[HAL 9000]

Ein Eintrag in der Prozessliste pro Zugriff... meinst du während des Zugriffst, oder bleiben diese Einträge nach dem Zugriff da? Letzteres ist bei mir nicht der Fall.
authz und passwd verwende ich nicht, ich habe zum testen einfach anonymen Schreibzugriff angeschaltet.
Dein Repository liegt auf einem USB-Speicher oder? Womöglich ist der einfach zu langsam? Ich werd das mal testen wenn ich wieder an meine 7140 rankomme (also heute Abend oder morgen). Bei meinen bisherigen Tests lag das Repository im RAM der Box.

 

[SvenFranz]

musste ein paar mal den Reposity-Browser beenden... danach bleiben die Einträge auf jeden Fall (bin aber auch da der Meinung, dass es gestern abend nicht so war, sonder so, wie du beschreibst)...

 1116 root       1068 S   /var/tmp/openvpn --config /var/tmp/server.ovpn
 1120 root        576 S   /var/tmp/svnserve -d -r /var/media/ftp/PikoBusiness2-
 1125 root        316 S   init
 1136 root        812 S   /var/tmp/svnserve -d -r /var/media/ftp/PikoBusiness2-
 1191 root        812 S   /var/tmp/svnserve -d -r /var/media/ftp/PikoBusiness2-
 1192 root        452 S   /var/tmp/dropbear -r /var/tmp/dropbear_rsa_hostkey

Ich teste weiter... irgendeinen Grund muss es ja geben, warum es gestern lief und heute nicht mehr...

Gruß
Sven

 

[SvenFranz]

Die Probleme scheinen nur aufzutreten, wenn man anonymen Schreibzugriff deaktiviert (vielleicht mache ich da auch noch was falsch!)...
wenn ich in der svnserve.conf "anon-access = write" aktiviere, ist es auch bei mir schnell und die Prozessliste sieht ok aus!

Gruß
Sven

 

[fritzichecker]

Hi danke HAL 9000 an die vorkompilierten files. Hat wunderbar hingehauen. Meine Tests waren sowohl mit kleinen Dateien als auch mit 1,92 MB großen Dateien recht flott. Allerdings wie Sven schon beschrieben hat nur mit anonymen zugriff. hatte noch keine Zeit anderes zu testen. Werde dies aber noch nachholen.
Gruß
fritzchecker

 

[HAL 9000]

Meine 7140 läuft jetzt wieder, und zumindest der anonyme Zugriff funktioniert super. Ich benutze im Moment ssh zur Zugangskontrolle, aber nicht-anonym direkt über svn werde ich auch nochmal ausprobieren.
Top sagt übrigens, dass 90% der Last während eines Commits für I/O draufgehen. Scheint so als wäre tatsächlich der USB-Stick der Flaschenhals. Einen frischen Freetz-Checkout zu importieren dauert bei mir etwa 20 Minuten... :|

Edit: Jetzt hab ichs auch mal ohne anonymen Zugriff ausprobiert (anon-access=none), und ich merke keinen Unterschied zu vorher...

 

[SvenFranz]

Edit: Jetzt hab ichs auch mal ohne anonymen Zugriff ausprobiert (anon-access=none), und ich merke keinen Unterschied zu vorher...

Seltsam... ich habe es ein paar mal ausgetestet... und immer wieder das selbe...
Gruß
Sven

 

[SvenFranz]

Habe diesbezüglich noch mal was gefunden... vielleicht hilft es ja?

Accessing non-public repositories via svnserve is really slow sometimes.

This often happens when APR is compiled to use /dev/random and the server is unable to gather enough entropy. If Subversion is the only application using APR on the server, you can safely recompile APR with the --with-devrandom=/dev/urandom option passed to configure. This should not be done on systems that use APR for other processes, however, as it could make other services insecure.

(http://subversion.tigris.org/faq.html)

Gruß
Sven

 

[SvenFranz]

Hi
könnt ihr mal testen, was

cat /dev/random

bei euch ausgibt? bei mir kommt nichts...
wenn ich aber

cat /dev/urandom

ausführe, bekomme ich lauter "zufällige" Zeichen...

Gruß
Sven

 

[HAL 9000]

Das da gar nichts kommt sollte aber nicht so sein... aber so arg viel krieg ich da auch nicht, jedenfalls nicht verglichen mit meinem PC. Ich werds bei Gelegenheit mal mit urandom versuchen, danke für den Tipp