it-swarm-eu.dev

Jsem geolog Subversion, proč bych měl / a uvažovat o Mercurialu nebo Gitu nebo jiném DVCS?

Snažím se pochopit výhody distribuovaného systému pro správu verzí (DVCS).

Našel jsem Subversion Re-education a tento článek by Martin Fowler velmi užitečný.

Mercurial a další DVCS propagují nový způsob práce na kódu s changesety a místními závazky. Zabraňuje sloučení pekla a dalších problémů se spoluprací

To nás nijak neovlivňuje, protože cvičím nepřetržitá integrace a pracovat samostatně v soukromé pobočce není možné, pokud nebudeme experimentovat. Používáme větev pro každou hlavní verzi, ve které opravujeme chyby sloučené z kmene.

Mercurial vám umožní mít poručíky

Chápu, že to může být užitečné pro velmi velké projekty, jako je Linux, ale nevidím hodnotu v malých a vysoce spolupracujících týmech (5 až 7 lidí).

Mercurial je rychlejší, zabírá méně místa na disku a úplná lokální kopie umožňuje rychlejší protokoly a operace s rozdílem.

Tohle mě taky nezajímá, protože jsem si nevšiml problémů s rychlostí nebo prostorem u SVN, a to ani u velmi velkých projektů, na kterých pracuji.

Hledám vaše osobní zkušenosti a/nebo názory od bývalých geeků SVN. Zejména s ohledem na changesets koncept a celkový výkon , který jste měřili.

UPDATE (12. ledna) : Nyní jsem přesvědčen, že to stojí za pokus.

UPDATE (12. června) : Polibek jsem políbil a líbilo se mi to. Chuť jeho třešňových místních závazků. Mercurial jsem políbil jen proto, abych to vyzkoušel. Doufám, že to můj server SVN nevadí. Bylo to tak špatně. Cítil se tak dobře. To neznamená, že jsem dnes večer zamilovaná .

ZÁVĚREČNÁ AKTUALIZACE (29. července) : Měl jsem tu čest zkontrolovat Eric Sink další knihu s názvem Verze Kontrola podle příklad . Nakonec mě přesvědčil. Půjdu na Mercurial.

304
user2567

Poznámka: Odpověď na aktuální otázku viz „EDIT“


Nejprve si přečtěte Subversion Re-education Joel Spolsky. Myslím, že většina vašich otázek tam bude zodpovězena.

Další doporučení, Linus Torvaldsův rozhovor o Gitu: http://www.youtube.com/watch?v=4XpnKHJAok8 . Tento druhý může také odpovědět na většinu vašich otázek, a je to docela zábavná.

BTW, něco, co mi připadá docela vtipné: dokonce i Brian Fitzpatrick a Ben Collins-Sussman, dva z původních tvůrců Subversion, řekli v jednom Google talk "omlouvám se", když se odkazovali na Subversion, který je horší než Mercurial (a DVCS obecně).

Nyní, IMO a obecně, týmová dynamika se vyvíjí přirozeněji s jakýmkoli DVCS a vynikající výhodou je, že se můžete zavázat offline, protože to zahrnuje následující věci:

  • Nezávisíte na serveru a připojení, což znamená rychlejší časy.
  • Nebýt otrokem na místech, kde můžete získat přístup k internetu (nebo VPN), abyste se mohli zavázat.
  • Každý má zálohu všeho (soubory, historii), nejen serveru. Význam serveru se může stát kdokoli .
  • Můžete nutně spáchat, pokud potřebujete , aniž byste kódům ostatních zasílali zprávy . Závazky jsou místní. Když se dopouštíte, nestoupáte si navzájem na prsty na nohou. Narušíte stavbu nebo prostředí druhých pouhým zavázáním.
  • Lidé bez „odevzdání přístupu“ se mohou dopustit (protože zapojení v DVCS neznamená nahrání kódu), snížení bariéry pro příspěvky, můžete se rozhodnout stáhnout jejich změny nebo ne jako integrátor.
  • Může to posílit přirozenou komunikaci, protože DVCS to činí nezbytným ... v Subversion to, co máte, jsou závodní rasy, které nutí komunikaci, ale znemožňují vaši práci.
  • Přispěvatelé se mohou spojit a zvládnout své vlastní slučování, což nakonec pro integrátory znamená méně práce.
  • Přispěvatelé mohou mít své vlastní pobočky, aniž by ovlivnili ostatní “(v případě potřeby je však mohou sdílet).

O vašich bodech:

  • Slučovací peklo v DVCSlandu neexistuje; není třeba s ním manipulovat. Viz další bod .
  • V DVCS každý představuje „větev“, což znamená, že dochází ke sloučení pokaždé, když jsou vyvolány změny. Pojmenované větve jsou další věc.
  • Pokud chcete, můžete i nadále používat nepřetržitou integraci. Není to nutné IMHO, proč přidat složitost ?, prostě si ponechte testování jako součást vaší kultury/politiky.
  • Mercurial je v některých věcech rychlejší, v jiných je git rychlejší. Ne ve skutečnosti až na DVCS obecně, ale na jejich konkrétní implementaci AFAIK.
  • Každý bude mít vždy celý projekt, nejen vás. Distribuovaná věc má co do činění s tím, že se můžete místně zavázat/aktualizovat, sdílení/odebírání mimo počítač se nazývá tlačení/tahání.
  • Znovu si přečtěte Subversion Re-education. DVCS jsou jednodušší a přirozenější, ale liší se, nesnažte se myslet, že cvs/svn === základna všech verzí.

Přispěl jsem nějakou dokumentaci k projektu Joomla, abych pomohl kázat migraci na DVCS, a zde Udělal jsem několik diagramů pro ilustraci centralizovaného vs distribuovaného.

Centralizované

alt text

Distribuované v běžné praxi

alt text

Distribuováno na maximum

alt text

V diagramu vidíte, že stále existuje „centralizované úložiště“, a toto je jeden z oblíbených argumentů fanoušků centralizované verze: „stále jste centralizováni“, a ne, nejste, protože „centralizované“ úložiště je pouze úložiště všichni se shodují (např. oficiální repetice githubu), ale to se může kdykoli změnit.

Toto je typický pracovní postup pro open-source projekty (např. Projekt s masivní spoluprací) využívající DVCS:

alt text

Bitbucket.org je poněkud ekvivalentem githubu pro Mercurial, vím, že mají neomezené soukromé úložiště s neomezeným prostorem, pokud je váš tým menší než pět, můžete jej použít zdarma.

Nejlepší způsob, jak se můžete přesvědčit o použití DVCS, je vyzkoušet DVCS, každý zkušený vývojář DVCS, který použil svn/cvs, vám řekne, že to stojí za to a že nevědí, jak přežili celý svůj čas bez něj.


[~ # ~] editovat [~ # ~] : Pro odpověď na vaši druhou úpravu mohu jen zopakovat, že s DVCS máte jiný pracovní postup, Doporučuji vám, abyste nehledali důvody, proč je nezkoušet, protože osvědčené postupy, je to jako když lidé tvrdí, že OOP není nutné, protože mohou obejít složité návrhové vzory s tím, co vždy dělají s paradigmatem XYZ, přesto můžete těžit.

Zkuste to a uvidíte, jak práce ve „soukromé pobočce“ je ve skutečnosti lepší volbou. Jedním z důvodů, proč mohu říci, proč je poslední pravdou, je to, že ztratíte strach ze spáchání , což vám umožňuje spáchat kdykoli vidíte, že je fit a pracuje přirozenějším způsobem.

Pokud jde o „slučování pekla“, říkáte „pokud experimentujeme“, říkám „i když experimentujete + maintaing + pracujete současně ve vylepšeném v2. “. Jak jsem říkal dříve, slučovací peklo neexistuje, protože:

  • Pokaždé, když se zavazujete, že vytvoříte nejmenovanou větev, a pokaždé, když se vaše změny setkají se změnami jiných osob, dojde k přirozenému sloučení.
  • Protože DVCS shromažďují více metadat pro každý odevzdání, během sloučení dochází k menším konfliktům ... takže byste to mohli dokonce nazvat „inteligentní sloučení“.
  • Když narazíte na sloučení konfliktů, můžete použít toto:

alt text

Nezáleží také na velikosti projektu, když jsem přešel od Subversion, skutečně jsem viděl výhody, když jsem pracoval sám, všechno se prostě cítilo dobře. changesety (ne přesně revize, ale konkrétní sada změn pro konkrétní soubory, které obsahují potvrzení, izolované od stavu kódové základny) vám umožní vizualizujte přesně to, co jste mysleli tím, že děláte to, co jste dělali, konkrétní skupině souborů, nikoli celé kódové základně.

Co se týče toho, jak fungují changesety a zvyšování výkonu. Pokusím se to ilustrovat příkladem, který ráda uvedu: přepínač projektu mootools ze svn ilustrovaný v jejich graf github sítě .

Před

alt text

Po

alt text

Vidíte, že vývojáři se mohou při zavádění soustředit na svou vlastní práci, aniž by se obávali porušení kódu ostatních, obávají se, že po stisknutí/vytažení kódu vylomí ostatní (DVCS: nejprve odevzdat, poté push/pull, poté aktualizovat) ), ale protože sloučení je zde chytřejší, často to nikdy neudělají ... i když dojde ke sloučení (což je vzácné), trávíte jej pouze 5 minut nebo méně.

Mé doporučení pro vás je hledat někoho, kdo umí používat Mercurial/git a říct mu, aby vám to vysvětlil hands-on. Když jsem strávil asi půl hodiny s některými přáteli na příkazovém řádku a používal Mercurial u našich stolních počítačů a bitbucketových účtů, ukazoval jim, jak se sloučit, a dokonce jim vymýšlel konflikty, aby viděli, jak se opravit v směšném množství času, dokázal jsem ukázat je to skutečná síla DVCS.

Nakonec bych doporučil použít Mercurial + bitbucket místo git + github, pokud pracujete s lidmi z Windows. Mercurial je také jednodušší, ale git je silnější pro složitější správu úložišť (např. git rebase ).

Několik dalších doporučených údajů:

333
dukeofgaming

Hovoříte mimo jiné o tom, že pokud v podstatě zůstanete na jedné větvi, nepotřebujete distribuovanou správu verzí.

To je pravda, ale není to zbytečně silné omezení vašeho způsobu práce, a to, které není dobře škálovatelné na více místech ve více časových pásmech? Kde by měl být centrální server Subversion umístěn a měli by všichni jít domů, pokud je server z nějakého důvodu nefunkční?

DVCSes jsou Subversion, co Bittorrent je ftp

(technicky, nikoli legálně). Možná, že pokud si to myslíte, můžete pochopit, proč je takový velký skok kupředu?

Pro mě, náš přechod na git, okamžitě vyústil

  • Naše zálohy jsou snadnější (stačí „vzdálená aktualizace git“ a máte hotovo)
  • Snadnější provádění malých kroků při práci bez přístupu do centrálního úložiště. Jednoduše pracujete a synchronizujete se, když se vrátíte do sítě hostující centrální úložiště.
  • Rychlejší stavba Hudsona. Mnohem rychlejší použití git pull než aktualizace.

Zvažte tedy, proč je bittorrent lepší než ftp, a znovu zvážte svou pozici :)


Poznámka: Bylo zmíněno, že existují případy použití, kdy ftp je rychlejší a bittorrentový. To platí stejným způsobem, jak se záložní soubor, který váš oblíbený editor udržuje, používá rychleji než systém pro správu verzí.

59
user1249

Zabijáckou funkcí distribuovaných systémů pro správu verzí je distribuovaná část. Nenecháváte pokladnu „pracovní kopii“ z úložiště, klonujete celou kopii úložiště. To je obrovské, protože poskytuje silné výhody:

  • Výhody kontroly verzí si můžete užít, i když nemáte přístup k internetu, jako je ... Tento je bohužel nadměrně využíván a přehnaný, protože DVCS je úžasný --- není to prostě silný prodejní bod, protože mnozí z nás se ocitají v kódování bez přístupu k internetu tak často, jak začíná pršet žáby.

  • Skutečným důvodem, proč má lokální úložiště, je zabiják, že máte úplnou kontrolu nad vaší historií odevzdání, než se dostane do hlavního úložiště.

Opravili jste někdy chybu a skončili s něčím jako:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

A tak dále. Historie, jako je tato, je chaotická --- skutečně existovala pouze jedna oprava, ale nyní je implementace rozšířena mezi mnoho revizí, které obsahují nežádoucí artefakty, jako je přidání a odstranění debugovacích příkazů. U systému jako SVN je alternativou nezavázat se (!!!), dokud vše nepracuje, aby se historie udržovala v čistotě. Dokonce i poté chyby sklouzly a Murphyho zákon na vás čeká, aby vás brutalizoval, když velká část práce není chráněna verzí.

S lokálním klonem úložiště , které vlastníte , to vyřešíte, protože můžete přepisovat historii nepřetržitým přetáčením „opravit“ a „Jejda“ "odevzdá se" potvrzení chyby ". Na konci dne dostane jeden čistý odevzdání hlavní úložiště, které vypadá takto:

r321 Fixed annoying bug.

Tak by to mělo být.

Schopnost přepisovat historii je ještě silnější v kombinaci s větvením modelu. Vývojář může dělat práci, která je zcela izolovaná v rámci větve, a když je čas přenést tuto větev do kmene, máte celou řadu zajímavých možností:

  • Proveďte prosté sloučení Vanilla . Přináší všechno na bradavice a všechno.

  • Proveďte rebasu . Umožňuje třídit historii poboček, znovu uspořádat pořadí odevzdání, vyhodit odevzdání, spojit odevzdání, přepisovat potvrzovací zprávy --- dokonce upravovat potvrzování nebo přidávat nové! Distribuovaný systém pro správu verzí má hlubokou podporu pro kontrolu kódu.

Jakmile jsem se dozvěděl, jak mi místní úložiště dovolila editovat svou historii kvůli zdravému rozumu mých kolegů programátorů a mého budoucího já, zavěsil jsem SVN navždy. Můj klient Subversion je nyní git svn.

Umožnit vývojářům a manažerům vykonávat redakční kontrolu nad historií odevzdání vede k lepší historii projektu a mít k dispozici čistou historii, která mi opravdu pomůže pracovat jako programátor. Pokud vás celá tato diskuse o „historii přepisování“ vyděsí, nebojte se, protože právě pro to jsou centrální, veřejné nebo hlavní úložiště. Historie může být (a měla by!) Přepsána až do okamžiku, kdy ji někdo přivede do větev v úložišti, ze kterého ostatní stahují. V tomto okamžiku by se s historií mělo zacházet jako s vyřezávanými na kamenné desce.

46
Sharpie

odpověď dukofgamings je asi tak dobrá, jak to dokáže, ale chci k tomu přistupovat z jiného směru.

Předpokládejme, že to, co říkáte, je absolutně pravda, a že použitím osvědčených postupů se můžete vyhnout problémům, které DVCS bylo navrženo k opravě. Znamená to, že by vám DVCS nenabízel žádnou výhodu? Lidé smrdí při dodržování doporučených postupů. Lidé jsou jedo, aby se pokazili. Proč byste se tedy vyvarovali softwaru, který je navržen k vyřešení řady problémů, místo toho byste se měli spoléhat na to, že lidé dělají něco, co můžete předem předvídat, že nebudou dělat?

18
philosodad

Ano, bolí to, když musíte sloučit velké závazky v Subversion. Ale to je také skvělá zkušenost s učením, díky čemuž děláte vše možné, abyste se vyhnuli sloučení konfliktů. Jinými slovy, naučíte se často se kontrolujte . Včasná integrace je velmi dobrá věc pro každý společně umístěný projekt. Dokud to všichni dělají, nemělo by být používání Subversion velkým problémem.

Například Git byl navržen pro distribuovanou práci a povzbuzuje lidi, aby pracovali na vlastních projektech a vytvářeli vlastní vidličky pro (eventuální) sloučení později. Nebylo to nikoliv konkrétně navrženo pro kontinuální integraci do „malých a vysoce spolupracujících týmů“, což OP žádá. Je to spíše naopak, pomysli na to. Nebudete mít žádné využití pro své fantazie distribuované funkce, pokud vše, co děláte, je sedět ve stejné místnosti a spolupracovat na stejném kódu.

Takže pro společně umístěný tým využívající CI, opravdu si nemyslím, že na tom záleží, pokud používáte distribuovaný systém nebo ne. To se scvrkává na otázku vkusu a zkušeností.

9
Martin Wickman

Protože byste měli neustále zpochybňovat své vlastní znalosti. Máte rádi Subversion a já tomu rozumím, protože jsem ji používal mnoho let, a byl jsem z toho velmi šťastný, ale to neznamená, že je to stále nástroj, který by vám nejlépe vyhovoval.

Věřím, že když jsem ho začal používat, byla to nejlepší volba v té době. Postupem času ale přicházejí i jiné nástroje, a teď dávám přednost gitům, dokonce i pro své vlastní projekty pro volný čas.

A Subversion má určité nedostatky. Např. Pokud přejmenujete adresář na disku, nebude přejmenován v úložišti. Přesun souboru není podporován, takže přesunutí souboru provádí operaci kopírování/mazání, takže sloučení změn, když byly soubory přesunuty/přejmenovány, je obtížné. A sloučení sledování není ve skutečnosti zabudováno do systému, ale je implementováno ve formě řešení.

Git tyto problémy řeší (včetně automatického zjišťování, zda byl soubor přesunut, nemusíte mu dokonce říkat, že je to fakt).

Na druhé straně vám git neumožňuje větvení na jednotlivých úrovních adresářů jako Subversion.

Moje odpověď zní: měli byste prozkoumat alternativy, zjistit, zda vyhovuje vašim potřebám lépe, než co znáte, a pak se rozhodnout.

8
Pete

S ohledem na výkon má Git nebo jakýkoli jiný DVCS oproti SVN velkou výhodu, když musíte přepínat z jedné větve na druhou nebo přeskočit z jedné revize na druhou. Protože je vše uloženo lokálně, věci jsou mnohem rychlejší než pro SVN.

To samo o sobě by mě mohlo přimět k přepnutí!

7
Xavier Nodet

Místo toho, abyste se věnovali myšlence, že „použitím nejlepších postupů nepotřebujete DVCS“, proč neuznat, že pracovní postup SVN je jeden pracovní postup, s jednou sadou doporučených postupů a pracovní postup GIT/Hg je jiný pracovní postup, s jinou sadou osvědčených postupů.

git bisect (a všechny jeho dopady na hlavní úložiště)

V Gitu je velmi důležitým principem to, že můžete najít chyby pomocí git bisect. To provedete tak, že vezmete poslední spuštěnou verzi, o které bylo známo, a první verzi, kterou jste spustili, o které bylo známo, že selhala, a provedete (s pomocí Gitovy pomoci) binární vyhledávání, abyste zjistili, které potvrzení způsobilo chybu. Aby to bylo možné, musí být celá vaše historie revizí relativně bez dalších chyb, které mohou ovlivňovat vaše hledání chyb (věřte tomu nebo ne, ve skutečnosti to funguje docela dobře, a vývojáři Linuxového jádra to dělají pořád).

Dosáhnout git bisect schopnost rozvíjet novou funkci na vlastní větev funkce , znovu ji vymalovat a vyčistit historii (takže nemáte žádné známé jiné -pracovávání revizí ve vaší historii - jen spousta změn, které vás každý dostane do cesty k vyřešení problému), a poté, když je funkce hotová, sloučíte ji do hlavní větve s pracovní historií.

Aby tato práce fungovala, musíte mít disciplínu ohledně toho, ze které verze hlavní větve spustíte větev funkcí. Nemůžete jen začít od současného stavu větve master, protože to může mít nesouvisející chyby - takže radou v komunitě jádra je začít pracovat od nejnovější stabilní verze jádra (pro velké funkce) ) nebo zahájit práci od posledního označeného kandidáta na vydání.

Meziproces můžete také zálohovat mezitím přesunutím větev prvku na server a můžete větev prvku poslat na server a sdílet ji s někým jiným a vyvolat zpětnou vazbu, než bude funkce dokončena, než budete muset proměňte kód v trvalý rys kódové základny, se kterým se každý ve vašem projektu musí vypořádat.

Manuální stránka gitworkflows je dobrým úvodem do pracovních postupů, pro které je Git navržena. Také Proč je Git lepší než X pojednává pracovní postupy gitu.

Velké, distribuované projekty

Proč potřebujeme poručíky ve vysoce spolupracujícím týmu se správnou praxí a dobrými designovými návyky?

Protože do projektů, jako je Linux, je zapojeno tolik lidí, kteří jsou tak geograficky rozloženi, že je těžké spolupracovat stejně jako malý tým, který sdílí konferenční místnost. (Mám podezření, že pro vývoj velkého produktu, jako je Microsoft Windows, že i když jsou všichni lidé ve stejné budově, je tým příliš velký na to, aby udržel úroveň spolupráce, díky které bude centralizovaná VCS fungovat bez poručíků.)

3
Ken Bloom

Proč je nepoužívat v tandemu? Na mém aktuálním projektu jsme nuceni používat CVS. Udržujeme však také lokální úložiště git, abychom mohli vyvíjet funkce. To je to nejlepší z obou světů imo, protože můžete vyzkoušet různá řešení a ponechat si verze toho, na čem pracujete, na svém vlastním počítači. To vám umožní vrátit se k předchozím verzím vaší funkce nebo vyzkoušet několik přístupů, aniž byste se při problémech s kódem dostali do problémů. Centrální úložiště vám pak přináší výhody centralizovaného úložiště.

2
Vadim

Nemám žádné osobní zkušenosti s DVCS, ale z toho, co jsem získal z odpovědí zde a některých souvisejících dokumentů, nejzásadnějším rozdílem mezi DVCS a CVCS je použitý pracovní model

DVCS

Pracovní model DVCS je, že děláte izolovaný vývoj. Vaše nová funkce/bugfix vyvíjíte izolovaně od všech ostatních změn až do okamžiku, kdy se rozhodnete jej uvolnit zbytku týmu. Do té doby můžete dělat, co se vám líbí, protože nikdo jiný se tím nebude obtěžovat.

CVCS

Pracovní model CVCS (zejména Subversion) je ten, že děláte rozvoj spolupráce. Vaše nová funkce/bugfix vyvíjíte v přímé spolupráci se všemi ostatními členy týmu a všechny změny jsou okamžitě k dispozici všem.

Jiné rozdíly

Další rozdíly mezi svn a git/hg, jako jsou revize vs changesety, jsou náhodné. Je velmi dobře možné vytvořit DVCS na základě revizí (jak je má Subversion) nebo CVCS na základě changesetů (jak je mají Git/Mercurial).

Nebudu doporučovat žádný konkrétní nástroj, protože to většinou závisí na pracovním modelu, s nímž jste vy (a váš tým) nejpohodlnější.
Osobně nemám problémy s prací s CVCS.

  • Nemám strach z kontroly věcí, protože nemám žádné problémy dostat ho do neúplného, ​​ale kompatibilního stavu.
  • Když jsem zažil slučovací peklo, bylo to v situacích, kdy by se to stalo v svn i git/hg. Například V2 nějakého softwaru byla udržována jiným týmem pomocí jiného VCS, zatímco jsme vyvíjeli V3. Opravy chyb by se občas musely importovat z V2 VCS ​​do V3 VCS, což v podstatě znamenalo provést velmi velkou kontrolu na V3 VCS (se všemi opravami v jediné changesetu). Vím, že to nebylo ideální, ale bylo to rozhodnutí vedení používat různé systémy VCS.