Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Komu se nelení,
tomu se zelení.

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Programování [ŽP: neomezená] (kategorie Programování) moderuje tvx.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: zpdxkkp
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 2.4.2009 13:23  1018
KdokolivNemáš pravdu. I checkout na filesystemu 8.3 lze provést bez rozbití. Z pohledu verzovacího systému, samozřejmě. Pokud tam máš například C++ kód a odkazuješ se na header mající ve jméně víc znaků než 8.3, pak ano, o určitém rozbití lze mluvit. Ale nikoliv o rozbití repozitáře. Klient si klidně může udělat překladovou tabulku a jména souborů zakódovat do podoby, kterou třeba používá(l) Windows 95, tj ve tvaru JMENOS~1.TXT.

Ani s tím druhým nesouhlasím. Verzovací systém podle téhle logiky totiž nemusí ani podporovat Branch & Merge. Degraduješ verzovací systém pouze na Backup & Restore. Ale tak to není, verzovací systémy mají umožnit zejména jednodušší vývoj a správu zdrojových souborů. Umožnit třeba vyvíjet více alternativ a přitom udržet nějakou rozumnou míru přehlednosti a integrity. A právě možnost vytvářet hardlinky se schopností se automaticky aktualizovat patří mezi nástroje Branch & Merge. Pokud si totiž branchnu půlku (nebo celý) projekt s tím, že chci stále mít aktuální určitou část projektu, na které nebudu pracovat, pak mi nezbývá, než maunálně mergovat. Kromě opruzu, to zbytečně zabírá místo v repozitáři, protože jde o dvě nezávislé větve u kterých prostě přestalo fungovat COW.

Mezi věci, které by měl verzovací systém umět podle mého názoru je třeba možnost dynamického mergování (soubor vzniká mergem z několika zdrojů), propagace změn jedním směrem (můj commit obsah souboru nepropaguje, ale commit z ostatních sdílení se automaticky zamergují). A podobně. Mohu ti říct, že není větší opruz, než když jsi připraven provést merge do trunku a po tom, co to uděláš zjistíš, že mezitím přišel nějaký blbec z vedení a rozhodl se totálně překopat celou knihovnu, na které je tvůj projekt závislý. Kdyby existovala možnost automatické aktualizace, dozvěděl by ses třeba o tomto kroku dřív a neztratil bys dny, či týdný vývoje zbytečnosti.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 2.4.2009 12:07  1017
Bredy [1013]: Jiste, ale jde o to, ze budes-li mit v repository veci, ktery neodpovidaj 8.3 a provedes checkout na MS-DOSu, tak se Ti to rozbije a nelze z toho vinit verzovaci system, ale jenom ten DOS. Stejne tak budu-li mit v repository symlinky a provedu checkout na Windows, tak se mi to rozbije a zase to je jenom chyba Windows.
Kazdopadne podle me pozadavek na to, aby se Ti samy updatovaly nejak soubory podle toho, jestli v ruznych mistech mas stejne, nebo ruzne revize, je proste podle me neco, co jde daleko za to, co bych aspon ja po verzovacim systemu chtel. Podle me proste verzovaci system ma umet vytvaret snapshoty aktualniho stavu a ma davat moznost se k nim vracet. Cokoliv navic uz podle me neni verzovaci system. Stejne tak jako podle me neni funkci antiviru hlidat, jestli nechodim na phishingove stranky (abych uvedl zcela nesouvisejici priklad, kde se ale projevuji podobne postupy zeslozitovani, o nez ne kazdy stoji).
bredy 2.4.2009 12:00  1016
ještě noticka... NTFS umí hardlinky tak jak linux. NTFS neumí symlinky, ale adresáře lze linkovat přes junction points. Nutno dodat, že valná většina softu s tím nepočítá a tedy pokud někdo pomocí junction pointu vyrobí cyklus, pravděpodobně zacyklí všechny stromové procházecí algoritmy. Dalším takový pseudosymlinkem ve Windows je "zástupce". Bohužel, ty repsektuje pouze ShellApi, klasické WinAPI je vidí jako obyčejné soubory.

Windows Vista prý podporuje jak hardlinky tak symlinky na úrovni WinAPI
bredy 2.4.2009 11:56  1015
tvxNo ono je v celku jedno, jestli to umi filesystem WC, důležitější je, že to neumí SVN obecně... tedy přesněji, všechny soubory jsou hardlinky, a můžeš ze dvou míst ukazovat na jeden soubor, ale pouze na specifickou revizi. To je přesně ten efekt kopírování, že kopie se neprovádí fyzicky, ale jen se vytvoří další link. Je to princip COW (copy on write). Dokud se soubor nezmění, tak je sdílen, jakmile se v jedné větvy změní, změní se pouze v té větvi.

Nemůžeš tedy vytvořit link ve smyslu na nejnovější revizi který by ti zajistil, že při změně souboru, který v adresáři referuješ automaticky dostaneš jeho nejnovější verzi...

... i když, stále doufám, že nějaká nová verze by to umět mohla... ale třeba ten důvod, proč to nejde je hlubší, vyplývající ze způsobu vnitřní organizace dat...
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 11:42  1014
Windoze (NTFS) umej hardlinky, dokoce je sam system v par mistech pouziva... jen se s tim, nevim proc nechlubej a nema to krom jakehosi exace junction.exe zadnou podporu...
bredy 2.4.2009 11:05  1013
KdokolivJeště námitka k MSDOSu. Proč bych neměl používat SVN pro vývoj nad MSDOSem? Omezení 8.3 není omezení, pakliže jména souborů dodržují i v repozitáři? Nejde tady o technickou záležitost, ale o možnosti v organizaci projektu, které jsou dost omezeny. Odvolávat se na omezenost WC? Repozitář je souborový systém sám pro sebe, a operací checkout a commit je možné souborový systém emulovat na omezené WC. Konečně, žádný filesystém nepodporuje svn property a přesto zrovna právě tohle SVN umí dobře emulovat.

Zatím se na git nechystám.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 2.4.2009 11:01  1012
Bredy [1010]: Akorat asi spolu nesouhlasime v tom, jak by to mel ten verzovaci system resit. :-) Kazdopadne ja SVN temer neznam (ciste jenom jako uzivatel, ktery si parkrat stahnul nejcerstvejsi verzi nejakeho zverejneneho projektu), takze jeho klady a zapory posuzovat nemuzu. Jenom vim, ze spousta lidi driv presla z CVS na SVN a dneska spousta lidi prechazi ze SVN na git, takze predpokladam, ze treba i z tohohle pohledu by git moh bejt lepsi (nicmene jeho schopnosti z hlediska symlinku/hardlinku neznam).
bredy 2.4.2009 10:55  1011
tvxTeď něvím, co přesně řešíš. Pokud to co já a Kdokoliv, tedy synchronizaci společných částí bez nutné restrukturalizace projektu, pak problémem nejsou jednorázová řešení, ale dlouhodobě nutnost starat se o aktuální stav nasdílených zdrojáků mezi projekty.
bredy 2.4.2009 10:52  1010
KdokolivBez ohledu na to vést s tebou nesmyslnou polemiku o symlincích s tebou souhlasím v jedné věci:

Stejne tak by mel verzovaci system idealne zvladat i hardlinky, aspon teda mezi souborama, ktery jsou soucasti tehoz repository (v jinych pripadech chapu, ze by to mohlo byt obtizne).

S tím, že na filesystémech, které toto neumí lze tuto funkcionalitu dobře emulovat ... například tak, že změna mezi soubory, které ve verzovacím systému sdílí jeden node (harlink) se projeví po sekvenci commit a update. Tohle by mi úplně stačilo.

A přesně tohle SVN neumí, což považuji za vadu.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 2.4.2009 10:37  1009
Bredy [1007]: Ano, je to problem Windows. Zalezi proste na tom, jake si stanovis pozadavky na OS, ktere povazujes za minimalni. Kdyz bude mit verzovaci system na MS-DOS potize s tim, ze MS-DOS neumi soubory delsich nazvu nez 8.3, tak to bude taky problem verzovaciho systemu? Ne, bude to problem MS-DOSu. Stejne tak si muzem vymyslet jine obskurni (at uz fakticky existujici, nebo proste jenom hypoteticke) platformy s jinymi podivnymi omezenimi filesystemu, na nichz proste nektere veci nemohou dobre fungovat.
A ja s Tebou proste nesdilim nazor, ze by verzovaci system mel jit za uroven spravy souboru tak, jak jsou ve filesystemu, tedy ze by mi mel napriklad menit obsah jednoho souboru, pokud se zmeni obsah jineho souboru. Verzovaci system ma umet verzovat. Cili ma mi umet udrzovat rekneme casovou osu obrazu filesystemu, nic vic, nic min. Tudiz kdyz si vytvorim symlink, kterej ukazuje do mista, kde zadnej soubor neni, tak k tomu ma presne takto verzovaci system pristoupit. Treba problem CVS je ten, ze on kazdej symlink commitne, jako kdyby to byl obycejnej samostatnej soubor v danym miste (teda pokud vim), cimz pochopitelne vznikaj problemy. Stejne tak by mel verzovaci system idealne zvladat i hardlinky, aspon teda mezi souborama, ktery jsou soucasti tehoz repository (v jinych pripadech chapu, ze by to mohlo byt obtizne).
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 10:35  1008
Bredyta spoluprace projektu... to me napada, ze bych takhle moh provozovat ty dve ruzny verze jednoho systemu...
proste bych zalozil teda hromadny repozitory, importoval projekt 1
potom bych ho zkopcil jako projekt 2, v ramci repozitory.
posleze checkout projektu 2 do lokalni kopie.....
tam uz uplne nevim jak, aby to SVN zkouslo, bych nejak zamenil ziskanej zdrojak za aktualni zdrojak puvodniho projektu... a commitnul to...
prijde ti to systemovy a proveditelny?
oba projekty samozrejme sdilej vsechny velkou cast spolecnyho kodu knihoven atd.
to sdileni bycch asi musel prolinkovat coz nevim jak je pruchozi a nebo bych si musel z aktualizaci v jedny verzi vzdycky odhodit potrebne zmeny i do druhe, coz asi pujde snadneji...
bredy 2.4.2009 10:22  1007
tvxČíslování revizí je pro někoho zavádějící, protože to vypadá, že se mění celá repozitář, ale není tomu tak. To číslo jen vyjadřuje nějaký historický milník, umožňující referovat zdroje do historie.

Máš pravdu, že pro zadané číslo revize jsi schopen sestavit celou repozitář. Ale neznamená to, že je to tak i uložené. Příklad: Když vytáhnu revizi 10, přesto mi do WC přileze soubor s revizí 3, prostě proto, že v daném adresář není žádná novější verze toho souboru. Pokud ho změníš a commitneš, uloží se s revizí 11.

Já třeba používám jeden repozitář, protože se mi lépe vytváří vztahy mezi projekty, pokud tam jsou. Naopak nemám zkušenosti s externals, který prý umožňují aktualizovat z externích zdrojů. Sám používám pravidlo pro spolupráci části zdrojáků
1) úzká spolupráce - v rámci jednoho projektu
2) volnější spolupráce - projekty v rámci repozitáře
3) žádná nebo velice lehká spolupráce - samostaný repozitář
4) externí knihovny (jiných autorů) - samostatný repozitář.

Kdokoliv:
1) Předpokládá se, že je podporuje operační systém.
2) Vyžaduje stahovat zdroje tech symbolických linků.

Ad1)napříkald windows. Nechci slyšet, že je to problém Windowsu. I kdybych se rozhodl vyvíjet třeba v MSDOSu, nebo na nějaké jiné exotické platformě, prostě symbolické linky jsou něco extra a verzovací systém by s tím neměl počítat.

Ad2) Například, pokud nasdílím takto zdroják z /trunk/project1/sources/lib/extralib/linux/aaa/includes/zdroj.h do /trunk/project2/zdroj.h, pak, aby mi to fungovalo, musím do svého WC stahovat i project1, nebo minimálně tuto šílenou cestu.

Od verzovacího systému bych očekával, že bude spíš simulovat funkcionalitu, že nasdílené zdroje jsou ve skutečnosti separátní zdroje, které si navzájem propagují updaty. Tedy pokud nasdílím jeden soubor na tři místa, pak commitem do jednoho souboru se provede propagaci změn na ostatní místa, jako bych to provedl ručně. Tohle mi SVN bohužel neposkytuje a považuji to celkem za zásadní vadu.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 2.4.2009 10:03  1006
Bredy [1004]: Muzes priblizit, v cem jsou ty symbolicky linky nesystemovy? Teda za predpokladu, ze s nima verzovaci system umi pracovat (narozdil treba od CVS).
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 09:35  1005
aha, to je dost podtsatny, to je to jednodussi nez jsem cekal... takze dana repozitory je v dane verzi vzdy cela... se vsema vetvema, vsechny tagy teda taky jakoby nejsou mrtvy ale roste jim ono spolecne cislo verze, jen se nemeni. Takze kdys se pak hejbe v trunku kde je vic projektu verzovani verze jednoho projektu hejbou se jakoby i ostatni?

ja jsem pro kazdej projekt zalozil jeho vlastni repozitory... coz jak ctu asi neni bezna praxe...

bredy 2.4.2009 08:55  1004
tvxV tomhle ti SVN moc nepomůže. SVN má jeden obrovský problém, nepodporuje sdílení zdrojů. Když nakopíruju jeden soubor do tří složek, tak je prostě nakopíruju a jsou to tři soubory. Linuxáci to neřešej, pro ně to řeší OS, takže se to dělá tak, že soubory leží ve čtvrtém adresáři a do těch tří se nalinkují jako symbolické linky. Z hlediska správy repozitáře nesystémové... ale co dělat, svn je prostě zdarma.

Verzovací system typu svn je velice primitivní. Je třeba jen dbát na to, abys měl všechno v repozitáři. Dále se odprostit od klasického "diskového" přístupu a přijmout fakt, že vyrobit kopii celého stromu neznamená v SVN fyzické kopírování souborů, ale jen vytvoření adresáře, který ukazuje na stejné soubory a podadresáře (a právě že ukazuje jen staticky podle čísla revize, sdílení jako takové je nemožné).

Jinak je dobré si organizovat repozitář tak jak doporučují tvůrci. Mít branches, trunk, tags. V trunku mít aktuální stav zdrojáků, v branches si vyvíjet alternativní cesty a do tags dávat uzavřené stavy projektu (projektů). Typicky, dokončíš-li vývoj nějaké verze, vyrobit její kopii v tags/číslo_verze

Seznam používal do nedávna organizaci, kdy měl v trunk jeden velký projekt představující "Seznam Fulltext" a v tom měl hromady zdrojáků bez ladu a skladu tak jak se to hodilo. Protože to byl obrovský bordel (důsledek přechodu ze CVS na SVN), během roku 2008 se to přeorganizovalo. Nyní máme v trunk adresáře, kde každý adresář je jedena komponenta obsahující vše co potřebuje ke svému plnohodnotného sestavení.

Ještě existuje jedna varianta, a to je projektová organizace, kde repozitář nejprve obsahuje projekty, a pak každý projekt obsahuje branches, trunk, tags. Sám nevím, co je lepší.

[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt