Portál AbcLinuxu, 28. července 2025 20:20
Linus pro změnu tvrdí, že jediné dva VCS, které stojí za úvahu, jsou git a Mercurial, git just does it better. Já nevím. V Sunu a Mozille se rozhodli pro Mercurial (v Mozille s poznámkou, že git je o dost lepší, ale prostě neběží na Windows), takže to asi nebude takové ořezávátko. Osobně znám jenom CVS (velmi letmo) a hlavně Subversion, takže poradit nemůžu.
Co já jsem kdekoliv četl, tak SVN je naopak vedle CVS vychvalováno...
Ale ano, Subversion je lepší svými možnostmi, však to také není nic jiného, než CVS 2.0. Ale všimněte si toho spojení "pro mě osobně". Nechci to rozmazávat, protože o to tu nejde, ale mě vyhovuje, když můžu jednoduše zazipovat celé CVS repository a pokračovat v práci na jiném počítači. Vyhovuje mi, že pokud dělám sám, nepotřebuji si hrát na žádný server, prostě CVS nasměruji na repository a jedu. Vyhovuje mi, že CVS jede kromě Linuxu i na starších verzích Windows, protože Subversion prostě pod Windows XP nic nepodporuje. Zkrátka nemám u Subversionu jistotu, že bude chodit na ničem jiném, než nejnovějším os+programech, například Apache 2.0 už není pro mě podporováno, takže by mě čekal zbytečný upgrade. Prostě politika Subversionu - podporovat jen to nejnovější a jinak nic není to, co by mě zavalilo nadšením vůči němu. Ale prosím, tohle je osobní názor, a o tohle nejde, tak to nerozmazávejme. Jak CVS, tak Subversion je prostě jen dlouho ohřívaná polívčička, v zásadě jen oprášený a vylepšený klon starého RCS ze sedmdesátých let. Rád bych se podíval spíše do jiných vod.
Co sa tyka WinXP, tam to s tym ukoncenim podporty tak rychle nebude, lebo velmi vela ludi ma zamer rovnaky ako Ty, t.j. zostat pri winxp tak dlho, ako to len pojde. Myslim ze vyvojari svn su si toho dostatocne vedomi.
Dovod, preco si non-gui program robi take naroky, nie je v tom non-gui, ale podla mna v tom, ze je network-intesive. Naroky by som videl tam, co program pouziva, nie tam, kde nic nepouziva, nie?
SVN odnesies presne tak, ako ja cvs. Ak si si zvykol hackovat cvs-metadata vo working copy resp. priamo v repozitari, to je Tvoj problem. Robis asi nieco, co nebolo dizajnovane. Nemozes cakat, ze tato "nedizajnovana funkcionalita" CVS bude podporovana jeho replacementom SVN. Aky problem vlastne nemozes riesit z SVN? Working copy sa da zbalit v praci, rozbalit doma, pracovat, zbalit, rozbalit v praci, commitnut.
Dovod, preco si non-gui program robi take naroky, nie je v tom non-gui, ale podla mna v tom, ze je network-intesive. Naroky by som videl tam, co program pouziva, nie tam, kde nic nepouziva, nie?
A co by používal na síti, nebo jinde, co ve Windows 2000 není? Mě to není jasné. Matně mi připomíná debatu s vývojáři PHP poté, co přestali podporovat jednu verzi Windows a odůvodnili mi to tím, že je to serverový program. Dodnes nezapomenu na překvapivý tón odpovědi, když jsem jim napsal v angličtině: "PHP je obyčejný skriptovací jazyk, nic víc, žádný serverový program. Apache je pravý serverový program, MySQL je pravý databázový server a oba mají menší nároky, než PHP, které serverovým programem není a nikdy nebylo." Což uznali a poté mi uschopnili PHP tak, aby pracovalo stejně jako Apache a MySQL pod tehdy současnou verzí Widnows.
Ak si si zvykol hackovat cvs-metadata vo working copy resp. priamo v repozitari, to je Tvoj problem.
Nezvyknul, ale to je jedno. Princip je ten, že CVS má pro mě vyšší užitnou hodnotu. Každý správce verzí by IMHO měl být široce a masívně multiplatformní, respektive já to požaduji od správce verzí. A SVN už pozoruji delší dobu, že podporuje jenom to právě nejmodernější a nejnovější z hlediska platforem. Proto na SVN nechci vázat své zdrojáky.
Navíc jak už jsem psal, chci vyzkoušet něco jiného, než je CVS, či SVN. Takže informace o mých názorech píšu jen proto, že by třeba někomu mohly posloužit, ale rád bych se podíval do jiných vod.
MySQL je pravý databázový serverTady se malinko rozcházíme
. (IMHO mysql je oblíbený hlavně kvůli skvělému phpmyadminu.)
MySQL je pro některá nasazení tím nejvhodnějším SQL serverem. Moudrý člověk nepoužívá nějaká konkrétní řešení jen na základě předsudků ("pche, MySQL, to používají jen looseři a stupidní PHP kodéři, praví c00l hax0ři používají jedině [dosaďte si váš oblíbený databázový server]"), ale na základě toho, které řešení je nejvhodnější pro danou situaci.
Btw. MySQL používá i třeba takový Google, to také o něčem vypovídá...
Kódování v MySQL funguje dobře, pokud používáte MySQL 4.1. Přímo špičkově. V MySQL verze 5.x došlo ke značným předělávkách a nejspíš to stále nestačili odladit, byť už je to dávno označeno za stable verzi. Setkal jsem se s rozbitým kódováním a chybami v této části MySQL 5.x už mockrát, a proto radím zatím MySQL 5.x nepoužívat.
Proto také v mém WAMP řešení web serveru není MySQL 5.x, ale MySQL 4.1, protože podstatná pro mě je absolutní spolehlivost a podpora toho nejhovějšího, co je spolehlivé: Complex Web Server.
Jinak ohledně chyb například PostgreSQL nebyla spolehlivou databází až do verze minimálně 6, takže já osobně jsem třeba tuto databázi vynechal pro značnou chybovost. Dneska už na ní spoleh je, ale hodně hodně dlouho trvalo, než se k tomu dospělo. Nebudí to ve mě moc dobrý dojem.
Nehodlám MySQL nijak zvlášť hájit, nicméně do verze MySQL 5 byla velmi velmi spolehlivá.
14.10.2008 14:58
15.10.2008 13:46
svn copysvn copysvn export je asi stotisíckrát jednodušší.svn/ adresářesvn rm dir/file a hned poté svn rm dir/, následný svn ci selže, protože nemůže odstranit již neexistující soubor v repository (napřed odstraní ten adresář a už nepozná, že nemá smysl odstraňovat ten soubor, pacholek jeden); je to děsný peklo, když refaktoruju.DS_Store souboryCo vadí na SubVersion mně:Naprosto šílené mergování! Ta mrcha mne klidně mergováním nechá vytvořit takový soubor, který nikdy v historii neexistoval, stačí zmergovat jednu revizi, ve které došlo ke změně, a nezmergovat jinou, ve které došlo ke změně též.
16.10.2008 11:34
svn merge z verze 1.4 je moderní IT ekvivalent útrpného práva!
O SVK jsem slyšel, určitě by to mohlo být užitečné třeba pro sledování nějakého projektu verzovaného v Subversion, nad kterým si chci dělat vlastní změny a verzovat si je taky v Subversion. Ale co vím, tak dneska už umí sledovat SVN i ostatní distribuované VCS.
Jasně že to je z principu průšvih, protože základní jednotkou pro SVN je soubor.Nerozumím jak jste to myslel. CVS je na tom líp? Já myslel, že atomické změny jsou hlavní výhoda. O distribuovaných VCS jsem toho moc neslyšel, takže asi proto to nechápu. Jak může mergování fungovat, když vyvíjíte ze stejného základu ve dvou nebo více větvích? Opravdové konflikty musí přece vždy vyřešit člověk ručně.
package). Kdyby SubVersion rozumněl zdrojovému kódu, pak by byl svět mnohem jednodušší. Například přesunutí bloku kódu do metody. Změna je to jedna: volání metody místo toho bloku — SubVersion to zase vidí jako "přešukání" souboru.
Zdrojový kód v Javě, C, C++, Perlu, bashi… je hierarchická struktura a merge by se měly dělat nad touto strukturou. Nikoli nad jejím zobrazení v řádcích (toto zobrazení je jen pro člověka, stroj jej nepotřebuje).
CSVPardon, CVS, samozřejmě
... ukládání kódu do nějaké strukturované databáze ... automaticky transformovat (refaktoring, mezijazykové konverze) ...S tím refaktoringem bych to tak růžově neviděl. Ale změny v repozitáři do MySQL ukládám i já
. V TapTindru to je kvůli testování/regresím.
V zaměstnání (PHP) to chci dělat kvůli sledování změn (sběr dat pro lepší odhadování, sledování interních atributů kvality kódu, sledování výkonnosti programátorů, sledování co bylo otestováno, napojení na systém pro požadavky, ...). Ale bohužel vymyslet se toho dá spoustu, horší je však najít někoho kdo by to realizoval. Parser na PHP šel zatím celkem vpoho, ale celkově je to spousta práce a sponzor žádný.
Jsem si vybavil, jak jsem měl na projektu rozjetý dvě další větve a jak jsem mergoval jak debil. Úplně mi při tý vzpomínce naskočila husí kůže
To je také důvod, proč mám "ještě" Tygříka a né Leoparda — prostě neopravuji to, co není rozbité
Nepomylil si sa?
Možná jsme se špatně pochopili. Spojením "pod Windows XP" jsem myslel, že subversion nejede pod nižšími verzemi Windows, než je XP. Chyba na mé straně, napsal jsem to neobratně.
Subversion mi přijde jako mírně prekabátěné CVS, a pro mě osobně má při srovnání CVS versus SVN více nevýhod spíše SVN.SVN je o moc lepší než CVS. Rozhodně není bezchybné, ale CVS by byl mor. Verze 1.5 už umí docela hezky mergovat. S Bazaarem nemám zkušenosti, ale Linux se při tvorbě Gitu inspiroval monotone. Projekt, kt. využívá monotone je třeba xaraya. Git si myslím, že rozhodně není špatný VCS, spousta projektů by na něj nepřecházela jen kvůli Linusovi.
(GIT vynechejme - otázkou je, zda by se GIT prosadil, kdyby ho nevymyslel Linus, navíc není ani multiplatformní, port pro Windows je silně hackerské dílo pochybné kvality.). Líbí se mi Bazaar, ale zatím nemám odvahu.Otázkou je, zda by se zda by se Bazaar prosadil, kdyby ho nevyvíjel Canonical Limited
. A myslím, že Git je docela dobře prověřován, linux kernel je dostatečně velký projekt na odhalení chyb.
Mně přijdou koncepčně monotone, Bazaar i Git podobné, takže bych prostě zkusil ten Bazaar, když je Vám sympatický.
Git si myslím, že rozhodně není špatný VCS, spousta projektů by na něj nepřecházela jen kvůli Linusovi.
Spousta projektů na něj přešla jen kvůli Linusovi. To ještě nevíte, co dokáže s lidmi udělat názor jedné známé osoby. Tenhle vliv bych rozhodně nepodceňoval, ve skutečnosti je to největší důvod, proč se Git vůbec ujal, a proč je přijímán.
A znovu říkám, že Git po několika letech je stále velmi mizerně multiplatfromní, a já od správce verzí požaduji bezproblémovou multiplatformost a minimálně bezproblémové a podporované klony na mainstreamové os. A podpora Windows, kterou též podtřebuji je v Gitu mizerná i po několika letech existence. Nejsem zvědavý na žádné běhy pod emulátorem Linuxu zvaným Cygwin, ani hackersky udělané msys klony, které byly narychlo spíchnuté, aby vůbec něco bylo.
A myslím, že Git je docela dobře prověřován, linux kernel je dostatečně velký projekt na odhalení chyb.
Nejde o počet chyb, jde o jeho princip, architekturu a přístup. Git byl vyvinut jako rychlý nalepovák, Linus ho spíchnul narychlo asi za 14 dní včetně principu, a myslel na potřeby vývoje Linux kernelu a na Linux - ostatní ho moc nezajímalo a dodnes je to na Gitu dosti znát. To je můj subjektivní názor, a tím se už ke Gitu nechci vyjadřovat - svůj účel, pro který byl vyvinut plní a plní dobře, takže není důvod proč Git pro tento účel nepoužívat a proč ho pro účely kernelu zbytečně kritizovat.
Otázkou je, zda by se zda by se Bazaar prosadil, kdyby ho nevyvíjel Canonical Limited
Souhlas Nicméně otázka je poměru kvality a prosazení autoritou.
Já osobně si netroufám distribuované VCS nějak hodnotit
Já se vyjadřoval ke gitu, ne k celé rodině distrobuovaných VCS a jenom jaký mám z toho dojem. Včetně fakta, že git je velmi špatně portován - a to za několik let jeho existence, což je fakt, který nemohu při praktické úvaze o použitelnosti pro mé osobní potřeby přehlížet.
Nedá mi to nevyjádřit se ke gitu - jestli není ideální, tak nechápu vývojáře velkých nekernelovských projektů, že na něj přecházeli.
Asi každý projekt má jiné potřeby, které jsou odlišné od těch mých. Nevím, proč hledáte nějaký objektovně 100% vhodný VCS pro všechny účely - neexistuje a nikdy existovat nebude. A znovu říkám, je za ním jméno Linuse a to dělá hodně. Nepodceňujte sílu slavného jména, to je schopno prosadit i méně kvalitní věci (aniž bych konkrétně hodnotil kvalitu gitu).
Docela zajímavé pojednání o gitu, včetně srovnání s Bazaar-NG a Mercurial: http://utsl.gen.nz/talks/git-svn/intro.html
14.10.2008 15:48
GandY | skóre: 3
| blog: Zo života
| Bratislava
14.10.2008 22:23
GandY | skóre: 3
| blog: Zo života
| Bratislava
gitu je Mercurial, Sun ho používá pro NetBeans a OpenJDK, takže to asi žádné ořezávátko nebude. Je napsaný v Pythonu, takže je multiplatformní (vyzkoušeno). Zatím jsem moc nezkoušel (převedl jsem jeden projekt z CVS do Mercurialu a udělal pár komitů, diffů a nějaké to divočejší mergování a falšování historie). Takže to nebyly jenom testy jako hraní, převedl jsem reálný systém, který bude na Mercurialu pokračovat, ale vývoje tam zatím moc nebylo. Ale princip se mi líbí (ale to by se mi líbil asi libovolný distribuovaný VCS), ovládání taky vypadá celkem rozumně. A když mám dělat diff nebo vývoj nad CVS nebo SVN, po distribuovaném VCS se mi stýská.
Mercurial, Sun ho používá pro NetBeans a OpenJDK, takže to asi žádné ořezávátko nebude.Sun také používá CVS pro openoffice.org (alespoň do nedávna tomu tak bylo)
.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.