2018-04-25 15:54 UTC


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000079Branch 0.2.1-FINALFeature Requestpublic2016-11-23 10:29
Reporteruser13 
Assigned Touser13 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformApache 2.2.9 - mod_php 5.2.6OSWindows Vista Ultimate x64 SP1OS Version6001 SP1
Product Version0.2.1-FINAL 
Target Version0.2.1-FINALFixed in Version0.2.1-FINAL 
Summary0000079: Lästiges database.php - Problem
Descriptionhttp://www.mxchange.stelzi.net.invalid/patches/database_rev-BEEP-Fix.patch

Habe mal versucht das lästige Problem zu lösen. Es muss bei jedem commit nur eine leere .revision-Datei (oder nur mit "neu" drinnen) geändert werden und das Script schreibt beim ersten Aufruf die richtigen Daten rein.

Nachteil: Wenn die datei manuell gelöscht oder geändert wird können da dann falsche Daten reingeschrieben werden.
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]
+Relationships

-Notes

~0000180

Quix0r (administrator)

So wie ich deinen Code versetehe, holt er sich von meinem Server die Daten, wenn z.B. "new" enthalten ist oder sie nicht existent ist?

Ich habe erstmal deinen Patch etwas umgeschrieben und an meine Funktionen READ_FILE(), FILE_READABLE() und WRITE_FILE() (Neu) umgeschrieben.

Was ich eigentlich haben will, ist, dass wie du schreibst, bei jedem Commit die Revisionsnummer eingetragen wird, damit das "Problem database.php nicht aktualisiert" beseitigt ist.

Oder plannst du das im naechsten Schritt?

~0000196

user13

Last edited: 2010-05-28 17:27

View 2 revisions

Also ich habs ja so gedacht, dass, wenn ein user Script bekommt (normal immer die aktuellste Rev), dass sich das Scritp die aktuelle Rev vom Server holt und in die .revision reinschreibt.

Aber irgendwie updatet svn die .revision-Datei nicht automatisch bei einem svn update. Bei svn export ist es egal, da ja dort immer alles überschrieben wird (außer config.php da ja in svnignore). Hm irgendwie verhext das alles mit einer Globalen Rev *grml*. Eine autorevert Eigenschaft gibt es auch nicht *grml*.

Ich hab ja eine ext-svn_update geplant, diese könnte die .revision automatisch schreiben oder auf "new" setzten.

http://www.mxchange.stelzi.net.invalid/patches/database_rev-BEEP-Fix2.patch habe ich mal eine Win-Batch-Datei gemacht. In TortoiseSVN kann man in den Optionen ein post-update-hook-Aktionsscript diese bat angegeben, dann wird die .revision zurückgesetzt.

~0000197

user13

Last edited: 2010-05-28 17:28

View 2 revisions

http://www.mxchange.stelzi.net.invalid/patches/database_rev-BEEP-Fix3.patch ist mein 3. Anlauf um dieses *BEEP* Thema endgültig zu erledigen. Jetzt sucht die Routine nach zuletzt geänderten Datei und sucht sich aus dieser Datei (unter anderem) die Rev.

Um dies zu ermöglichen muss in jeder Datei (vorzugsweise im DateiKommentar auch in TPLs als html-Kommentar, eventuell von der Temeplateengine herausgefiltert) folgende 3 Zeilen in genau dieser Reihenfolge stehen:

$Revision: 12347 $
$Date: 2009-02-10 17:51:10 +0100 (Mo, 12. Jän 2009) $
$Tag: 0.2.1-FINAL $

Dann muss auch die svn-Eigenenschaft auf jede Datei auf svn:keywords auf "Date Revision" (zumindest diese 2 Keywords) gesetzt werden.

Nun aktuallisiert SVN immer die Revision- und Date-Werte wenn diese Datei Commited wird.

Mit einem anfügen an die URL von "&check_revision_data=yes" wird die Revision neu ermittelt und eventuell falsche Werte überschrieben.

Die alte Methode mit dem vom Server lesen, habe ich mal drinnen gelassen und wird nur mehr als Fallback-Lösung benützt.

Eventuell könnte man auch einstellen, wenn man sich im Admin-Bereich befindet, dass die Revision immer neu eingelesen werden. Im Admin-Bereich fällt es nicht so sehr auf, wenn das Script so ca. 0,5 - 1 Sekunde (zumindest auf meinem PC) länger zum ausführen Braucht. Auch könnte man das Cache-Neuschreiben (.revision dabei auch löschen) zum neueinlesen benutzen. Auch könnte ich mir vorstellen, dass nur bei einem Login eines Admins oder beim aufruf der Update-Seite (Übersicht ob neue Version vorhanden ist) die Revision zur Sicherheit neu eingelesen wird.

Diese Lösung währe meiner Meinung nach die Lösung, die am sichersten funktioniert und keine möglicherweise falschen Werte wie das vom Server holen bringt.

~0000251

Quix0r (administrator)

Den ganzen Server bei jedem Aufruf (oder "nur" Adminbereich) halte ich fuer zu stark uebertrieben und die Serverlast ist enorm hoch.

Das mit den automatischen Tags kann ich problemloser in die 0.3.0 einbauen, als noch das gesamte Script (0.2.1-FINAL) erweitern.

~0000294

Quix0r (administrator)

Das kann jetzt mit deiner neuen Branch nervig sein. Somit waere die Konstante CURR_SVN_REVISION nie aktuell. :( Ich verzichte nur ungern auf diese Information. Aber es sollte eine Loesung her.

Und ab 0.3.0 sollte dies dann geloest sein, damit wir dies los sind. :)

Rausnehmen ist denke ich mal auch nicht sinnvoll, da dann die User uns nicht sagen koennen, welche Revision sie haben. Aber irgentwo koennen wir dann auch immer sagen: Bitte SVN-HEAD auschecken.

~0000295

Quix0r (administrator)

Ich denke, im Adminbereich sollte sie angezeigt werden, so wie du vorgeschlagen hast. Z.B. unter "Updates pruefen" wird dies ohnehin getan, wenn die Revision veraltet ist.

Das Ding ist nur, dass mein post-commit Script bei jedem (!) Commit die Datei REVISION auf dem Server neu schreibt. Dass heisst, auch diese ist nicht synchron, wenn der User sich z.B. 0.2.1-FINAL mit Revision 900 auscheckt, du an deiner Branch etwas aenderst und ploetzlich soll es (angeblich) eine neue Revision fuer 0.2.1-FINAL geben, aber es hat sich nur deine Branch geaendert.

Und mit 0.3.0 wird es hier auch nicht anders sein, wenn z.B. du oder ein weiterer Maintainer eine Branch hat und dort Commits macht.

~0000296

Quix0r (administrator)

Last edited: 2009-03-05 23:46

Scriptseitig habe ich da eine Idee. Branch-Script "FINAL" ueberprueft die Datei "REVISION-FINAL" und so weiter. Aber serverseitig muss wohl ein Shell-Script her, das den Commit analysiert und dann die passende Revisionsdatei aktualisiert.

~0000297

Quix0r (administrator)

Ich schaetze, mein Kommentar 0000296 wird wohl nicht so einfach sein. Erstmal muss die Versionsnummer zerlegt werden, damit wir an das Wort "FINAL" gelangen. So ist das Script (Core) flexibler gegenueber z.B. deiner Maintainer-Branch.

~0000307

Quix0r (administrator)

Sollte nun stabiler sein (hab deinen Code etwas angepasst).

~0000465

Quix0r (administrator)

Diese sollten nun auch gefixt sein.

~0000818

Quix0r (administrator)

Und zu damit.
+Notes

-Issue History
Date Modified Username Field Change
2009-02-09 15:24 user13 New Issue
2009-02-09 15:24 user13 Status new => assigned
2009-02-09 15:24 user13 Assigned To => user13
2009-02-09 16:51 Quix0r Note Added: 0000180
2009-02-10 15:18 user13 Note Added: 0000196
2009-02-10 18:10 user13 Note Edited: 0000196
2009-02-10 18:28 user13 Note Added: 0000197
2009-02-23 19:57 user13 Assigned To user13 => Quix0r
2009-02-23 22:39 Quix0r Note Added: 0000251
2009-03-05 23:27 Quix0r Note Added: 0000294
2009-03-05 23:27 Quix0r Priority normal => urgent
2009-03-05 23:27 Quix0r Product Version 0.2.1-FINAL =>
2009-03-05 23:36 Quix0r Note Added: 0000295
2009-03-05 23:37 Quix0r Note Added: 0000296
2009-03-05 23:46 Quix0r Note Edited: 0000296
2009-03-06 04:01 Quix0r Note Added: 0000297
2009-03-06 04:01 Quix0r Projection none => major rework
2009-03-06 04:01 Quix0r ETA none => 2-3 days
2009-03-09 02:45 Quix0r Note Added: 0000307
2009-03-09 02:45 Quix0r Assigned To Quix0r => user13
2009-03-09 02:45 Quix0r Status assigned => feedback
2009-11-25 21:55 Quix0r Build Rev 725 => SVN-725
2009-11-25 21:56 Quix0r Fixed in Version => 0.2.1-FINAL
2010-05-28 16:51 Quix0r Product Version => 0.2.1-FINAL
2010-05-28 17:27 Quix0r Description Updated View Revisions
2010-05-28 17:27 Quix0r Note Edited: 0000196 View Revisions
2010-05-28 17:28 Quix0r Note Edited: 0000197 View Revisions
2010-06-08 01:35 Quix0r Fixed in Version 0.2.1-FINAL =>
2010-06-23 13:56 Quix0r Note Added: 0000465
2010-06-23 13:56 Quix0r Status feedback => resolved
2010-06-23 13:56 Quix0r Fixed in Version => 0.2.1-FINAL
2010-06-23 13:56 Quix0r Resolution open => fixed
2016-11-23 10:29 Quix0r Note Added: 0000818
2016-11-23 10:29 Quix0r Status resolved => closed
+Issue History