Programování - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Něco navíc v zeleném?
A proč ne...

Lopuch.cz

	Klub Programování [ŽP: neomezená] (kategorie Programování) moderuje tvx.
	Archiv

Nastavení klubu

Nastavení práv

Homepage

Anketa

[ 857 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 14:43	1023
	samba jinak beha cca 4-6MB/s (tedy 40-60Mbit) v tomhle pripade je provoz temer nulovej.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 14:39	1022
	mas predstavu co se dej na pozadi? podle me komunikuje eclipse se svn a zada si od nej zasahy do ty WC coz je smazani souboru a vyrazeni z evidence ale to nemuze preci trvat takovou dobu ne? navic kdyz vsechny zarizeni jsou absolutne nevytizeny.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 14:35	1021
	server mam jako: samba pro working copy (je to web) a svn pres tunelovany ssh. ted narazil na soubory co jsem smazal a vzdy hlasi do logu: delete --force cesta k souboru bogus filanema svn: soubor does not existt.... jeden obrazek mu trva cca 30 sekund :(


	2.4.2009 14:24	1020
	tvxa server ti jede pres svnserver nebo pres sdileni souboru?


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 14:17	1019
	tak k ty pomalosti: mam teda repository i share na kterym pracuju na stejnym pocitaci a je to teda po lokalni siti... ale... jakykoli operace trvaj silene dlouho, treba ted delete 1000 jpeg souboru co se pripletly kde nemely... eclipse to trva uz asi pul hodiny ale porad leze, to je videt... na serveru ma otevrenej akorat soubor.svn/entries jinak nic sit je prazdna, jak lokalni pocitac tak server ma vytizeni 0.0nic... netusim, kde je problem... mate nekdo tip a zkusenost s eclipse a nejakou jeho okamzitou replikaci na server?


	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 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).


	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


	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 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...


	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 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).


	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.


	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 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).

[ 857 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


(c) 2001-2011 Lopuch.cz Kontakt