2024-03-19 07:05 CET


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000164Branch 0.2.1-FINALBugpublic2016-11-23 11:28
Reporteruser13 
Assigned Touser13 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformApache 2.2.x - mod_php 5.2.x OSWindows Vista Ultimate x64 SP1 OS VersionVista with SP1
Product Version0.2.1-FINAL 
Target Version0.2.1-FINALFixed in Version0.2.1-FINAL 
Summary0000164: Fehler in searchDirsRecursive() => Falsche Rev.-Ermittlung
DescriptionBedingt durch ein unerwartetes Verhalten von getArrayFromDirectory() werden nicht alle Dateien nach den Rev-Tag durchsucht. Ich glaube ich mappe alle gefundenen Verzeichnisse in ein Cache-Array rein, damit es dann schneller geht.
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]
+Relationships

-Notes

~0000410

Quix0r (administrator)

Kannst du bitte auch Projection, ETA und 'Product Build' aktualisieren? So pflege ich die Tickets. :) SVN-HEAD reicht als Product-Build bei dir aus, hast ja meistens immer HEAD. ;)

~0000411

user13

So habs noch nicht ganz fertig gefixt aber ich werke noch daran.

~0000412

user13

Quix0r kannst du mal prüfen ob ich da einen Fehler gemacht habe? Nach einer Neuinstallation wollte ich sql_patches registrieren. Da hats dann einen Fehler gegeben, dass es CURR_SVN_REVISION nicht von getConfig-her nicht finden konnte. Ich habe den Cache geleert, dann konnte es irgend eine andere template-variable von getConfig-her nicht finden. Kann es sein dass da irgendwie eine Race-Condition mit dem Config-System und der registrierung von sql-patches vorhanden ist?

~0000413

Quix0r (administrator)

Oder wollen wir nicht eher den ganzen Revisonskram rauswerfen, wenn der so viele Probleme macht? Nur dass ein Webmaster aka. Mailtauschbetreiber nicht die Finger krum machen will und die Revisionsnummer z.B. mit Hilfe von TortoiseSVN holen koennte, haben wir nun so viele Probleme und muessen die gesamte Verzeichnisstruktur einscannen, was viel Performance kostet?

Ich glaube, PHP bietet hier wo eine Extension, mit der wir auch Revisionsinformationen uns holen koennen.

~0000414

Quix0r (administrator)

Meiner Meinung nach sollten wir uns um das Wesendliche des Mailtausches kuemmern und nicht, welche Revision gerade beim User drauf ist. Die sehen die ohnehin, wenn die auschecken bzw. aktualisieren. :)

~0000420

Quix0r (administrator)

Ich schaue mir aber dennoch deinen Patch an. Irgentwie kann ich mich dennoch nicht davon trennen. :(

~0000421

Quix0r (administrator)

Ich hab den Bug jetzt selber finden koennen, ist aber nicht leicht zu erklaeren und nur durch viele logDebugMessage()-Zeilen findbar. :)

Erstmal hattest du in searchDirsRecursive() die Funktion getArrayFromDirectory() mit zwei vertauschten Parametern aufgerufen und zudem selbst rekursiv gesucht, was nicht noetig ist, da getArrayFromDirectory() schon recursiv sucht - ausser du willst es nicht. Dann hattest du immer nach der zuletzt geaenderte Datei gesucht, was beim Entwicklen dazu fuehrte, dass nur die korrekte Revisonsnummer angezeigt wurde, wenn du die Datei als letzttes editiert hast, was selten vorkommt.

searchDirsRecursive() habe ich nun so modifiziert, dass es nach neueren Dateien suchen kann und dabei die Revisionsnummer verwenden kann. Standart ist noch immer 'Date' (was vielleicht klappt?).

Dann hattest du in getActualVersion() ein [0] beim Verwenden des Cache-Arrays $GLOBALS['cache_array']['revision'] verwendet, was nicht noetig ist.

Ist alles beim naechsten Update mit dabei. Dein Patch in deiner Branch habe ich mir auch angesehen und bemerkt, dass du nicht gekapselst hast, sowie gute Funktionen wie getArrayFromDirectory() nicht mehr verwendet hattest (war irgentwo der Fall).

Ich hoffe, du bist dann mit meinem (kommenden!) Commit zufrieden. :)

~0000422

Quix0r (administrator)

Vergiss das mit [0], ist wohl doch wegen des Caches noetig. :(

~0000462

Quix0r (administrator)

Ich denke, dies sollte bereits gefixt sein. Sollte es wieder vorkommen, bitte neues Ticket aufmachen, da der Code starken Aenderungen unterliegt.

~0000797

Quix0r (administrator)

Und zu damit.
+Notes

-Issue History
Date Modified Username Field Change
2009-12-08 00:37 user13 New Issue
2009-12-08 00:37 user13 Status new => assigned
2009-12-08 00:37 user13 Assigned To => user13
2009-12-08 00:41 Quix0r Note Added: 0000410
2009-12-08 23:19 user13 Projection none => minor fix
2009-12-08 23:19 user13 ETA none => 2-3 days
2009-12-08 23:19 user13 Build => SVN-HEAD
2009-12-09 03:22 user13 Note Added: 0000411
2009-12-09 03:33 user13 Note Added: 0000412
2009-12-09 22:00 Quix0r Note Added: 0000413
2009-12-09 22:01 Quix0r Note Added: 0000414
2009-12-15 16:58 Quix0r Note Added: 0000420
2009-12-15 18:44 Quix0r Note Added: 0000421
2009-12-15 18:53 Quix0r Note Added: 0000422
2010-05-28 18:27 Quix0r Build SVN-HEAD => 0.2.1-FINAL
2010-05-28 18:36 Quix0r Product Version => 0.2.1-FINAL
2010-06-23 15:55 Quix0r Note Added: 0000462
2010-06-23 15:55 Quix0r Status assigned => resolved
2010-06-23 15:55 Quix0r Fixed in Version => 0.2.1-FINAL
2010-06-23 15:55 Quix0r Resolution open => fixed
2016-11-23 11:28 Quix0r Note Added: 0000797
2016-11-23 11:28 Quix0r Status resolved => closed
+Issue History