542 odpovědí na toto téma

[mr.mates]

Nerozpouštět prosíííím. Je to takto pohodlnější a rychlejší. A bůh ví, zda jimto bude fungovat :|

[maros251]

Jsem pro ponechat to tak jak to je. At si amici dělaj co chtěji.

[Archi1]

Prosím nerusit, je to mooc dobra vecicka! Díky.

[bossno]

Proč rušit něco co perfektně funguje? Vzpomeňte na loňský výpadek během požáru v blízkosti serverů GC. Každý sháněl data kde se dalo a i to byl jeden z důvodů, proč spustit tenhle projekt. A ten další je určitě veliké pohodlí - kliknu a mám, nemusím čekat až se někdo uráčí mi poslat aktuální data. Veliké díky všem a hlavně programátorovi.

[mlog]

Pokud to autora projektu nějak výrazně nezatěžuje, jsem taky pro zachování. Funguje to skvěle, tak proč to rušit? Šemíku, díky.

[martman]

zachovat - moznost stahnout si tesne pred cestou aktualni data bez nutnosti naklikavat 10 PQ je neocenitelna!

[Arne1]

je dobré zkontrolovat spam koš. Ze 4 PQ které jsem včera dostal na Centrum mi 3 skončily ve spam koši. Ví bůh proč....

[semik75]

Kdysi mě někdo žádal, jestli by bylo možné aby v agregovaných PQ bylo víc než 5 posledních logů. V nové verzi to možné bude. Teď to mám nastavené na 30, ale snížit to nebude problém. Potřeboval bych ale vědět co by se stalo, když by to byl default který by se nabízel všem? Vidíte v tom nějaký problém pro GSAK a ostatní programy co používáte? Velikost zatím neřešte. Pro ty kteří potřebují šetřit pásmo budou k dispozici nějaké změnové balíky a pravděpodobně nakonec povolím i ten rsync.

[Hickos]

Co se týče GSAK bych to neviděl jako problém.

[medwyn_cz]

U GeoGetu take bez problemu.

[zde]

> Pro ty kteří potřebují šetřit pásmo budou k dispozici nějaké změnové balíky a pravděpodobně nakonec povolím i ten rsync. Kdyby byl denní diff/rdiff, tak bych osobně rsync vůbec nepotřeboval. Jo a všiml jsem si že v GPX souboru se pořadí keší bůhví proč občas mění, takže by se před tím diffem zřejmě hodila i nějaká normalizace (setřídění).

[semik75]

zde napsal/a:
Kdyby byl denní diff/rdiff, tak bych osobně rsync vůbec nepotřeboval. Jo a všiml jsem si že v GPX souboru se pořadí keší bůhví proč občas mění, takže by se před tím diffem zřejmě hodila i nějaká normalizace (setřídění).

No stary system jednotlivky kesky cpe do perlovsky hashe takze je dost pravdepodobny ze kdyz nejaka keska ubude/pribude tak se cely strom presklada a poradi je jiny.

V novym systemu jsem pouzil pro ulozeni metadat mysql, takze to ve vystupu bude vzdy ve stejnem poradi,

Denni diff je mozna az moc malo. Premyslim o tom, ze krom kompletniho baliku bude k dispozici i balik s keskama ktery se za poslednich n-dni zmenily (tedy listing, logy, tb, wpts). 7dni mi pripada jako dostatecny aby se to dalo delat rucne, tj. to mohlo pouzit vic lidi. Uvidim jak velky soubory to bude generovat... Import historickych dat jeste furt nedobehl, ale uz tam skoro budu. Ted jsem u 22.2.2010

[Osik]

semik75 napsal/a:
Denni diff je mozna az moc malo. Premyslim o tom, ze krom kompletniho baliku bude k dispozici i balik s keskama ktery se za poslednich n-dni zmenily (tedy listing, logy, tb, wpts). 7dni mi pripada jako dostatecny aby se to dalo delat rucne, tj. to mohlo pouzit vic lidi. Uvidim jak velky soubory to bude generovat...

rsync na .gpx by to řešil sám od sebe, a kdo chce, může ho dělat třeba každou hodinu. A nechat ten velký .ZIP pro on-line stažení ...
Já si rychle stahuju .zip (a rozbaluju) do práce a z domu po pomalé lajně dělám jen rsync ... Bohužel se balík dat přižene obvykle někde kolem páté, šesté večer, takže v práci to většinou nestihnu.

[HaLuMa]

Mimochodem, co zkusit misto rsync pouzit zsync? Ten si vystaci s obycejnym HTTP a na strane serveru nepotrebuje zadnou podporu, jen se vedle ten souboru vystavi i prislusne vygenerovane soubory s kontrolnimi soucty.

viz. http://www.root.cz/c...po-beznem-http/

[Osik]

HaLuMa napsal/a:
Mimochodem, co zkusit misto rsync pouzit zsync? Ten si vystaci s obycejnym HTTP a na strane serveru nepotrebuje zadnou podporu, jen se vedle ten souboru vystavi i prislusne vygenerovane soubory s kontrolnimi soucty.

viz. http://www.root.cz/c...po-beznem-http/

Geniální nápad ... ale ... Udělal jsem nějaké testy a
- na ALL.zip prakticky nefunguje (stačí malá změna v GPX a ZIP je úplně jiný ...)
- na ALL.gpx funguje pěkně, ale data tahá nekomprimovaně, takže přenos je zase veliký ... Na hodinový mirror by možná fungoval, ale rozdíl 9.2. a 15.3. je 75% (45MB je stejných, 120MB se tahalo, to je lepší tahat 47MB ZIP kompletu...) Ještě zkusím nějaký menší rozdíl (asi budou nějaká data doma na záloze).
- zsync se netváří že by uměl https ...

[zde]

Osik: Máš nějaké zkušenosti s GITem? Je to použitelné na adresář s 10k+ soubory?

[HaLuMa]

V principu fungovani nevidim duvod, proc by zsync nemohl pouzivat https, ani proc by nemohl pouzivat kompresi pri prenosu. Spise to bude nedokonalost toho konkretniho klienta, kde se na tyto veci autori vykaslali.

[Osik]

zde napsal/a:
Osik: Máš nějaké zkušenosti s GITem? Je to použitelné na adresář s 10k+ soubory?

Bohužel ne. Jen jsem o tom četl.

[Osik]

HaLuMa napsal/a:
V principu fungovani nevidim duvod, proc by zsync nemohl pouzivat https, ani proc by nemohl pouzivat kompresi pri prenosu.

Spise to bude nedokonalost toho konkretniho klienta, kde se na tyto veci autori vykaslali.

- komprese funguje pěkně ... hraju si s tím lokálně, rozdíl 9.2.-15.3. je 34MB proti 47MB celku v ZIPu (podle mě se gzipují jen logy a nové keše)

- https nemám kde vyzkoušet, ale snažím se ...

Kdyby Semik zapracoval 'zsyncmake -z ALL.gpx' a 'zsyncmake -z ALL-wpts.gpx' tak by to bylo prima ...

[semik75]

Ja pokusoval s SVN a moc to nejde. Mam ted vsechny kesky ulozeny ve 4-5 samostatnych souborech (listing, wpts, logy, tb, changelog). Pri prekroceni nejakych 500000 failu to zacalo byt hodne pomaly. Prekvapenim bylo ze to nebrzdil SVN server jako takovy. Straslive dlouho trvalo nez si lokalni klient sesumiroval co vlastne chce na server poslat. Ta hranice bude pro kazdyho asi jina, me u toho pul mega dosla pamet na diskovy kese a pak to ani rychly SAS disky nezachranily. Po te co jsem tomu udelal vlastni virtual mi ten rsync vadit nebude.