Programování - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Náš Lopuch Vám
vytře zrak

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ší>


	Tessien Of course slavery is the worst thing - that ever happened. But maybe... 2.4.2009 17:12	1028
	tvx [1027]: clovece, kdykoli ctu nejaky tvoje dotazy, nemuzu se zbavit pocitu, ze tam vzdycky vsechno delas nejak ukrutne zbytecne slozite...


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 16:49	1027
	Tak jsem objevil FastSync, plugin co funguje jako builder ale misto buildovani mi provedene zmeny synchronizuje na uvedene misto, jen uvidim co a jak pristupovy prava na cili, jestli je udrzi pote co si tam nastavim


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 16:26	1026
	Inu, ac jsem tomu neveril je to tim ulozenim na siti... netusim kde je problem ale problem je, na disku se to chova celkem bleskove. Ted jeste nejaej synchronizator, protoze delat webovou apliakci aniz by slo hned videt vysledek je na prd.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.4.2009 15:05	1025
	Bredyno, bez svn mi to doted behalo jak po masle :( to preci neni mozny aby to pri tom ale negenerovalo nekakj traffic, tohle mi prijde jako snad nejaky nedorozumeni v ramci systemu kde neco ceka na neco atd. nebo netusim.


	2.4.2009 15:00	1024
	tvxTo nevím, ale osobně bych do takového experimentu nepouštěl. Při správě working copy se neprovádí jen nějaké kopírování souborů, třeba se tam vyměnují zámky. Nevím, tohle neznám. Ale osobně bych začal standardní cestou, tedy na lokále. WC je také k tomu určená. Pracovat přes sdílení souborů po sambě je dost šílenost.


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

[ 857 ]

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


(c) 2001-2011 Lopuch.cz Kontakt