Änderung im Dateiformat

[MiK]

Warum bemerke ich die Tatsache, dass etwas fehlerhaft ist, erst beim Zuweisen und nicht beim Lesen, das verstehe ich gerade nicht. Kann man es nicht einfach so machen:

isIncomplete =  false;

lese Wert1.
Wenn Problem, dann isIncomplete = true;
lese Wert2.
Wenn Problem, dann isIncomplete = true;
...

lese isIncompleteAusXML

isIncomplete = isIncomplete | isIncompleteAusXML

 

[greiol]

Warum bemerke ich die Tatsache, dass etwas fehlerhaft ist, erst beim Zuweisen und nicht beim Lesen, das verstehe ich gerade nicht.

weil wir nur zeichenketten lesen, die parsen wir anschliessend und weisen sie den eigenschaften zu. dabei treten fehler eher beim parsen auf als beim lesen einer zeichenkette.

Kann man es nicht einfach so machen:

äh doch, genau so könnte man das machen. ps:

 

[Geo-Johnny]

Da ich ja immer ein Backup der Daten im alten Format habe, habe ich mal zum testen die r1804 probiert. Dabei ist mir aufgefallen, daß einige Caches jetzt nichtmehr als gefunden markiert sind. Zuvor hatte ich 443 Funde in der DB, im neuen Format sind es 438 Funde. Bei einem Cache ist mir das nach der Entfernungssortierung gleich ins Auge gestochen, welche anderen Caches noch betroffen sind kann ich nicht genau feststellen. Dazu müßte ich eine ältere Version, parallel zur neuen Version laufen lassen und feste suchen. Die Icons wurden, soweit ich gesehen habe, richtig übernommen.

Dank "Engywuck" läuft der Garmin Export jetzt wieder über (.loc) wenn man die zusätzlichen Cacheinfos NICHT benötigt. Allerdings wenn man die Cacheinfos mitexportiert, ist mir auch ein Fehler aufgefallen.
Hackt man die Kurznamen an und setzt ein Hackerl bei Infos im Namen, erscheinen bei vielen Caches die Infos auch im Wegpunkt, besonders dann, wenn es sich um einen kurzen Cachenamen handelt.
Das war übrigens auch schon vor der Umstellung aufs neue Datenformat ...

L.G. - Johnny

 

[MiK]

Dank "Engywuck" läuft der Garmin Export jetzt wieder über (.loc) wenn man die zusätzlichen Cacheinfos NICHT benötigt. Allerdings wenn man die Cacheinfos mitexportiert, ist mir auch ein Fehler aufgefallen.

Welche Änderungen von Engywuck meinst Du? Das ging doch vor und nach der Formatumstellung.

Hackt man die Kurznamen an und setzt ein Hackerl bei Infos im Namen, erscheinen bei vielen Caches die Infos auch im Wegpunkt, besonders dann, wenn es sich um einen kurzen Cachenamen handelt.
Das war übrigens auch schon vor der Umstellung aufs neue Datenformat ...

Die Kurznamen werden von GPSbabel aus dem erzeugt, was CW in den Namen reinschreibt. Um das von Dir gewünschte zu erreichen, müsste CW die Kurznamen selbst erzeugen.

 

[Geo-Johnny]

Dank "Engywuck" läuft der Garmin Export jetzt wieder über (.loc) wenn man die zusätzlichen Cacheinfos NICHT benötigt. Allerdings wenn man die Cacheinfos mitexportiert, ist mir auch ein Fehler aufgefallen.

Welche Änderungen von Engywuck meinst Du? Das ging doch vor und nach der Formatumstellung.

Sorry, es war SKG ps:
1793 / salzkammergut 5d 19h 58m Export to Garmin (via .LOC file): Speedup by only loading cache details when necessary

Hackt man die Kurznamen an und setzt ein Hackerl bei Infos im Namen, erscheinen bei vielen Caches die Infos auch im Wegpunkt, besonders dann, wenn es sich um einen kurzen Cachenamen handelt.
Das war übrigens auch schon vor der Umstellung aufs neue Datenformat ...

Die Kurznamen werden von GPSbabel aus dem erzeugt, was CW in den Namen reinschreibt. Um das von Dir gewünschte zu erreichen, müsste CW die Kurznamen selbst erzeugen.

Okay, alles klar, Danke.

Übrigens bei den Caches die in der neuen Version nicht als gefunden dargestellt werden, dürfte es sich um Caches handeln, wo die Boxgröße nicht angegeben wurde. z.B. Tradis, Letterbox usw. ...
Bin mir noch nicht ganz sicher und grüble noch ...

 

[Geo-Johnny]

Dank "Engywuck" läuft der Garmin Export jetzt wieder über (.loc) wenn man die zusätzlichen Cacheinfos NICHT benötigt. Allerdings wenn man die Cacheinfos mitexportiert, ist mir auch ein Fehler aufgefallen.

Welche Änderungen von Engywuck meinst Du? Das ging doch vor und nach der Formatumstellung.

Sorry, es war SKG ps:
r1793 / salzkammergut 5d 19h 58m Export to Garmin (via .LOC file): Speedup by only loading cache details when necessary

Also ich habe es jetzt getestet. Bei r1738 ging es noch via LOC File, bei r1786 (die Letzte im alten Format) lief es über GPX und bei der r1804 läuft es wieder via LOC File.

 

[greiol]

so langsam wird es spannend.

ich versuche gerade meine änderungen zu testen und bei einigen exportern auf fehler gelaufen (ich nehme immer eine kopie meines profils mit den gefundenen caches zum testen).

ein vergleich mit einem export mit einer version die noch auf meiner platte lag und aus dem märz stammt zeigt allerdings, dass ich auch da schon bei einigen exportern probleme hatte (es entstehen null pointer exceptions). die zu grunde liegenden fehler dürften also schon länger im code sein.

mein dilemma ist nun folgendes:
der neue code könnte probleme (fehler) enthalten die über das mass hinausgehen die im alten code waren. bloss kann ich das natürlich nicht testen bis ich mich ganz nach unten durch gegraben habe und dann ist auch der alte code nicht mehr der alte code

auf der anderen seite laufen die versionen natürlich durch engywucks und meine änderungen immer weiter auseinander und wir müssen die branches irgendwann wieder mergen um nicht völlig den kontakt zu verlieren.

ich möchte eigentlich keinen code zurück spielen von dem ich weiss dass er fehler hat. anderesits ist auch der jetzige code scheinbar nicht ganz unproblematisch.

mergen - um von einer gemeinsamen codebasis aus die fehler zu suchen - oder nicht mergen, das ist hier die frage.

 

[Engywuck]

auf der anderen seite laufen die versionen natürlich durch engywucks und meine änderungen immer weiter auseinander und wir müssen die branches irgendwann wieder mergen um nicht völlig den kontakt zu verlieren.

Du kannst ja die Änderungen, die seit Deinem Branch im Hauptzweig passiert sind, auch in Deinen Branch reinmergen. Oder sieht Dein Code mittlerweile ganz anders aus, so dass der Merge schlecht möglich ist?

ich möchte eigentlich keinen code zurück spielen von dem ich weiss dass er fehler hat. anderesits ist auch der jetzige code scheinbar nicht ganz unproblematisch.

Och, so lange der Hauptzweig dann noch läuft - derzeit ist es halt etwas instabiler. Der Hinweis auf der Nightmare-Build-Seite sollte die Anwender davon abhalten, damit zu arbeiten.
So lange keine großen und offensichtlichen Fehler drin wären, hätte ich nichts dagegen, wenn es in den Trunk reinkommt. Dann können andere nämlich schon mit dem Code weiterarbeiten, wenn es denn benötigt wird.

Gruß,
E.

 

[Harry1999]

Ausserdem... so hat man die Chance gleich alle eventuell vorhandenen Fehler danach in Ruhe Stück für Stück zu beseitigen ohne zwei parallele Stränge aufzubauen.

 

[greiol]

auf der anderen seite laufen die versionen natürlich durch engywucks und meine änderungen immer weiter auseinander und wir müssen die branches irgendwann wieder mergen um nicht völlig den kontakt zu verlieren.

Du kannst ja die Änderungen, die seit Deinem Branch im Hauptzweig passiert sind, auch in Deinen Branch reinmergen. Oder sieht Dein Code mittlerweile ganz anders aus, so dass der Merge schlecht möglich ist?

klar merge ich die erst mal bei mir, aber irgendwann brauche ich halt den weg zurück nach trunk. und die änderungen betreffen inzwischen relativ viele dateien. ein merge ist immer möglich, wird aber natürlich aufwändiger je länger die zweige getrennt sind. andereseits war der branch notwendig, da ich ein paar tage gebraucht habe bis alles wieder kompilierte.

ich möchte eigentlich keinen code zurück spielen von dem ich weiss dass er fehler hat. anderesits ist auch der jetzige code scheinbar nicht ganz unproblematisch.

Och, so lange der Hauptzweig dann noch läuft - derzeit ist es halt etwas instabiler. Der Hinweis auf der Nightmare-Build-Seite sollte die Anwender davon abhalten, damit zu arbeiten.
So lange keine großen und offensichtlichen Fehler drin wären, hätte ich nichts dagegen, wenn es in den Trunk reinkommt. Dann können andere nämlich schon mit dem Code weiterarbeiten, wenn es denn benötigt wird.

also die grundsachen funktionieren alle: gpx import, gc spider und oc xml import habe ich jeweils mit den 100 nächsten caches getestet. probleme machen halt noch einige exporter, aber wie in einem anderen fred steht scheint das halt auch schon trunk zu betreffen. und in ein paar aspekten scheinbar schon die ganz alten exporter.

wenn wir uns da auf die suche machen, wäre es vielleicht gut von einer einheitlichen basis auszugehen. den königsweg dahin kenne ich halt bisher noch nicht.

Ich lass nachher mal einen dry-run laufen, dann sehen wir wo sich alles etwas ändern würde.

 

[greiol]

merge dry run experiments/greiol -> trunk

U src/CacheWolf/ShowCacheInBrowser.java
U src/CacheWolf/DetailsPanel.java
U src/CacheWolf/CalcPanel.java
U src/CacheWolf/Version.java
U src/CacheWolf/CacheSize.java
U src/CacheWolf/myTableControl.java
U src/CacheWolf/SpiderGC.java
U src/CacheWolf/CacheType.java
U src/CacheWolf/GPXImporter.java
U src/CacheWolf/Parser.java
U src/CacheWolf/CacheList.java
U src/CacheWolf/CacheHolder.java
U src/CacheWolf/myInteractivePanel.java
U src/CacheWolf/OCXMLImporter.java
A src/CacheWolf/GuiImageBroker.java
U src/CacheWolf/RadarPanel.java
U src/CacheWolf/MainTab.java
U src/CacheWolf/navi/GotoPanel.java
U src/CacheWolf/navi/MovingMap.java
U src/CacheWolf/myTableModel.java
C src/CacheWolf/FilterScreen.java
U src/exp/ExploristExporter.java
U src/exp/GPXExporter.java
U src/exp/MSARCSVExporter.java
U src/exp/Exporter.java
U src/exp/TPLExporter.java
U src/exp/TomTomExporter.java
U src/exp/KMLExporter.java
U src/exp/HTMLExporter.java
U build.xml
A resources/typeApe.png
A resources/typeMaze.png

das meiste würde bei einem merge also durchlaufen (ob es kompiliert steht auf einem anderen blatt ). bei src/CacheWolf/FilterScreen.java haben wir wohl etwas gemacht was sich widerspricht. das müssten wir dann noch auflösen. last changes sind noch nicht eingecheckt, dürften die liste aber nicht länger machen.

 

[MiK]

Ich bin auch für einen sofortigen Merge in den Trunk. Nur so können aktuelle Änderungen direkt mit dem neuen Format erfolgen.

 

[Engywuck]

Warum dry? Wenn Du eine Working Copy des letzten trunk-standes nimmst, ist der "feuchte" merge ja auch nicht gefahrvoller, weil das "revert" nur einen Klick entfernt ist.
Gruß,
E.

 

[greiol]

dry-run? weil ich zu der uhrzeit zu faul war über irgendwas nachzudenken und ich mit cvs immer noch vertrauter bin als mit svn. :schockiert:

mausklick? mit den verschiedenen varianten innerhalb von eclipse muss ich mich noch beschäftigen. bisher merge ich auf der kommadozeile. da fühle ich mich wohler

wenn es so weiter regnet, werde ich das wohl heute im laufe des tages erledigen. den konflikt muss ich mir nochmal in ruhe ansehen. ich stimme mich gerade mit engywuck ab.

 

[MiK]

dry-run? weil ich zu der uhrzeit zu faul war über irgendwas nachzudenken und ich mit cvs immer noch vertrauter bin als mit svn. :schockiert:

mausklick? mit den verschiedenen varianten innerhalb von eclipse muss ich mich noch beschäftigen. bisher merge ich auf der kommadozeile. da fühle ich mich wohler

Für etwas kompliziertere SVN-Operationen würde ich TortoiseSVN empfehlen. Außer natürlich man ist mit allen Befehlen und Optionen der Kommandozeile vertraut.

 

[greiol]

Für etwas kompliziertere SVN-Operationen würde ich TortoiseSVN empfehlen.

das tool hat für mich einen haken: Win2k SP4, WinXP, Vista or later

bisher greife ich im zweifel auf http://svnbook.red-bean.com/index.en.html zurück und mache halt einen dry-run mehr als unbedingt notwendig

 

[MiK]

Wie von Engywuck erwähnt: Auch ein richtiger Merge, wirkt sich erstmal nur auf Deine Working-Copy aus und nicht auf das SVN. Wenn es nicht läufst, revertest Du die Working-Copy vom Trunk einfach. Ansonsten Commiteste Du sie.

 

[greiol]

- ihr habt recht
- ich war gestern um mitternacht ziemlich müde
- ein dry-run macht erst mal weder beim server noch bei mir etwas kaputt
- es ist schlimmstenfalls ein zusätzlicher arbeitsschritt
- ich weiss gerne vor dem zusammenführen ob es garantiert knallen wird
- ihr habt recht

und jetzt hat es auch noch aufgehört zu regnen :-\

 

[MiK]

und jetzt hat es auch noch aufgehört zu regnen :-\

Mist ;-)

 

[Geo-Johnny]

Hallo, hier bei den Össis scheint die Sonne.
Besonders dann, wenn man zum Testen mal wieder ein NB (r1812) runterholt und nach ein wenig rumprobieren alles wie gehabt zu laufen scheint.
Meiner Freude darüber, habe ich mit einer bescheidenen Kontoauffrischung Ausdruck verliehen.
L.G. - Johnny