it-swarm-eu.dev

Jaké jsou vaše oblíbené systémy pro správu verzí?

Jedná se spíše o diskusní otázku než o skutečný pokus o určení „nejlepšího“, protože to se jasně liší podle potřeb organizace. Jsem více zvědavý na argumenty ve prospěch různých systémů napříč kategoriemi (centralizované vs distribuované, otevřené vs proprietární atd.).

Co si myslíte, že je nejlepší systém pro správu verzí?

41
Fishtoaster

Merkurial

Protože je to sofistikovaná schopnost větvení a slučování kódu, je to nejlepší, co jsem použil. Celé paradigma DVCS dává tolik smysl. Nepoužil jsem Git, ale předpokládám, že se také kvalifikuje.

81
epotter

Git

Git je fantastický, a zejména bych ho doporučil každému, kdo pracuje na open source projektech: je mnohem snazší přispět malou, jednorázovou změnou k projektu na Gitu, zejména pokud je jeho hostitelem na GitHubu, než se zabývá e- zasílání záplat o SVN.

Jedna velká výzva pro uživatele Windows: Nástroje společnosti Git pro Windows, i když jsou rozhodně použitelné, nejsou úplně na škrábnutí. Když jsem byl na chvíli nucen používat Windows, vyzkoušel jsem rozhraní Windows Mercurial s integračním nástrojem Hg-Git, abych mohl používat své úložiště Git a zjistil jsem, že je mnohem jednodušší používat.

72
Gaurav

Upozornění: Od tohoto příspěvku jsem našel Mercurial a miluji ho mnohem lépe než SVN. Tento příspěvek je tak trochu zastaralý s komentáři Pro SVN a obecnými anti-DVCS, ale anti-git věci jsou stále relevantní


Jsem fanouškem SVN přes Git.

Proč? Protože SVN bylo mnohem jednodušší pro jednoho vývojáře nebo malý tým, a git (konkrétně msysgit) mi nechal v ústech špatný vkus.

Když jsem se učaroval v malém obchodě, byl jsem představen, abych si zahrával na Windows. Okamžitě jsem si všiml, kolik práce to trvalo, než jsem začal pracovat s Githubem. Nejprve jsem musel vygenerovat soukromý klíč ssh, vložit veřejný klíč do Githubu, pak vyvolat průvod a otevřít svůj soukromý klíč pokaždé, když jsem chtěl Push, což bylo velmi nepříjemné.

A nikdy se mi moc nelíbilo, že jsem stahoval celé úložiště. Přiznám se, že jsem nikdy nepracoval s ničím obrovským, ale bál bych se stáhnout si úložiště KDE v Gitu, kdyby celé repo a jeho revize byly na mém HD.

Pak došlo k matoucímu procesu, který se zavázal. TMK, musel jsem nejprve "fáze" všechny soubory, které jsem chtěl zavázat (které cucal, když jste měli mnoho souborů, trvalo mi chvíli najít manuální příkaz k fázi vše), pak proveďte potvrzení, pak Push to the main repo (proč je to samostatná operace ?!).

Měli jste také ne (!) Velmi užitečná data potvrzení. Oh, podívej, jedná se o odevzdanou část stromu 2167a4934d0a4a7db0de a rodičovskou d7042abb4821d3faf600. K čertu to znamená? Měl bych být schopen rychle vymyslet věci a nemusím se dívat na nějakou podivnou dokumentaci.

Když už mluvíme o dokumentaci, alespoň když jsem ji používal, zdálo se, že všechno bylo ve formátu linuxového mužského souboru, IE matoucí a zbytečné pro mě. Zřídka jsem v dokumentech našel hodně pomoci a jednoduše se uchýlil google.

A se zavázáním, jedna věc, která se mi nelíbila, byl nedostatek čísel verzí. Teď vím, že je to kvůli návrhu gitu, ale jakýkoli software potřebuje číslo verze. Stále si pamatuji, že se značka zavázala, že se objeví vyskakovací okno „Změněná verze na 1.8.6“ nebo něco podobného, ​​ale stále jste nemohli vytvářet čísla. Abych měl verzi 1.8.8.5164 (poslední část je číslo revize), řekne mi to mnohem víc, než jen 1.8.6 a poznámku, že se něco menšího změnilo, zkuste to

Pokud jde o specifický software, základním programem v systému Windows je msysgit, což je hrozné rozhraní. Několikrát mě to zamklo, mělo hrozné rozhraní a integrace CLI-GUI byla přinejlepším iffy. Junkies z příkazového řádku kolem mě gui nenáviděl ještě víc.


Nyní se podívejme na SVN. A protože jsem na Windows a mám účet Google, konkrétně TortoiseSVN a Google Code.

Nejprve dokončete integraci Shell, abyste udělali vše v úložišti (a pro vás linuxové dělá RabbitVCS totéž), není třeba žádné hlavní GUI. Získání úložiště je snadné jako pokladna, není potřeba SSH (nelze si pamatovat, zda Github vyžadoval SSH pro tahy), a žádné celé repo + všechny minulé závazky se nesedí na vašem HD.

Potvrzení je extrémně snadné, hlavně proto, že není potřeba SSH nebo inscenace. Jednoduše zkontrolujete všechny soubory, které chcete, pomocí velmi užitečné možnosti Vybrat vše, které v mé verzi msysgitu nebylo k dispozici, napište zprávu potvrzení a stiskněte tlačítko potvrzení. Google Code poté požádá o vaše přihlašovací údaje (které většina klientů ukládá) a vaše hotové. Jednoduché, snadné a žádné SSH

Čísla verzí? S některým snadným kódem můžete ke všem pokladnám přidat číslo verze a číslo potvrzení, což vše mnohem zjednoduší. Získáte také použitelná čísla verzí, která skutečně ukazují změnu, např. 1.8.6.5165 je novější než 1.8.6.5164.

Dokumentace? Těžko říct. Želva je dokumentována, ale ve skutečnosti jsem na oficiální dokumentaci neodkázal tak dlouho, že to nedokážu soudit. Četba jednoduchého úvodního průvodce mi stačila.

Sloučení je něco jiného, ​​co nemohu porovnat. Musel jsem to udělat jednou v Gitu, když se někdo jiný dopustil změny v souboru, na kterém jsem pracoval, ale nikdy v SVN.


Který bych doporučil? Ve velkých týmech má git své výhody, hlavně v nelineárním vývojovém cyklu. V jiném projektu jsem viděl, jak začínají 4 programátoři v samostatných větvích, a poté spojí celý kód velmi podivným způsobem, který se nějak proměnil v závěrečnou hlavní větvi. Github a msysgit měli opravdu pěkný vizualizační nástroj pro celý projekt, který se mi opravdu líbil.

Pro projekty s jedním vývojářem nebo malé týmy by SVN byla nejlepší, protože většina funkcí Gits se nepoužívá a vaše jediná získávání negativních částí. Jednoduchost je taková pěkná věc

24
TheLQ

Následující citát z Q4TD to pro mě celkem shrnuje:

"Miloval jsem Gita, dokud jsem to nezkusil." Teď miluji Mercurial. “

- Tor Norbye, The Java Posse Podcast

Rovněž hgsubversion dělá docela dobrý klient Subversion pro Linux (kde obvykle používám příkazový řádek, na rozdíl od Windows, kde obvykle používám TortoiseSVN). Největší výhoda: ne .svn podsložka v každé složce, pouze .hg na nejvyšší úrovni.

Aktualizace: V reakci na Alexovu žádost v komentářích „řekněte více o tom, proč pro vás git nefungoval a jak Mercurial fungoval lépe“:

Neřekl bych, že Git pro mě nefunguje , ale Murcurial funguje lépe IMO.

Stručně řečeno, jedná se o Mercurial:

alt text

a to je Git:

alt text

A tvrdím, že Mercurial udělá vše, co bude většina vývojářů potřebovat, aniž by musel hledat příručku, aby zjistil, jak dělat každodenní věci.

Je pravda, že jsem Git používal jen občas, ale programovací komunita prošla gagou nad jazyky jako Ruby a Python, částečně, kvůli jejich stručnosti a eleganci, zatímco Git se cítí jako velbloud, který byl navržen komisí velbloudů.

Bah, teď se podívej, co jsi udělal? Všude je výkřik. Pohyb, nic vidět ... nic vidět ...

Aktualizace 2: A další apropos Tweet Právě jsem narazil:

"Git je snazší, jakmile získáte základní představu, že větve jsou homeomorfní endofunktory mapující podsložky Hilbertovho prostoru."

22
Evan

Nemám jediný „nejlepší“ systém řízení verzí, ale spíše jediný nejlepší paradigma VCS.

Použil jsem několik různých centralizovaných systémů pro správu verzí a několik různých distribuovaných systémů pro správu verzí. A mohu bez váhání říci, že nikdo by nikdy neměl na sebe zavést CVCS.

Nezajímá mě který DVCS, který si vyberete (můj konkrétní favorit je Git), ale prosím, udělejte laskavost a použijte DVCS. Za prvé: budete mnohem flexibilnější. DVCS mohou triviálně napodobit pracovní postup CVCS (prostě úložiště nikdy nerozvětvujte a vaše lokální úložiště považujte pouze za mezipaměť namísto nezávislé vidlice), zatímco obrácení je nemožné. A zatímco logicky, když děláme tuto emulaci mělo by nést nějakou režii (a opravdu to dělá), já stále je pro mě snazší používat (nemluvě o mnohem výkonnější díky místní ukládání do mezipaměti) než kterýkoli z CVCS, které jsem použil.

14
Jörg W Mittag

Nelze říci, že jsem narazil na nejlepší software pro správu verzí, ale mohu vám říci, abyste se drželi dál od VSS a MKS. Oba jsou psi, kterým by se za každou cenu nemělo vyhýbat.

11
Walter

Neřekl bych to nejlepší, ale s velmi zajímavými rysy a koncepty.

Fossil je distribuovaná kontrola verzí, sledování chyb a projekt wiki postavený na databázi SQLite jako úložiště.

7
Maniero

Team Foundation Server

Protože:

  1. Je to dobrý, solidní VCS. (V žádném případě bych to nepovažoval za nejlepší, ale má pěkné doplňky.)
  2. Její vestavěné sledování úkolů a chyb, které se integrují do Visual Studio, mi pomáhá zůstat soustředěný a vědět, na čem musím pracovat na jednom místě (automatické použití check-inu na chybu nebo úkol a jeho uzavření je docela dobré, i když můžete získejte pluginy pro jiné systémy/Eclipse/atd., abyste to mohli udělat.)
  3. Integruje úkoly/sledování chyb/projekty přímo do Project Serveru, takže jen zřídka někdy musím aktualizovat plány projektů nebo časové rozvrhy. Aktualizace projektu na serveru Project automaticky filtrují dolů jako úkoly do TFS a do Visual Studio, abych je viděl automaticky.
5
Ryan Hayes

Ve své dlouhé historii jsem použil mnoho systémů pro správu verzí:

  • RPPT role pásky děrovaného papíru). V krabici na boty. Nedělám si legraci.
  • PVCS - (Polytron Version Control System). První skutečný VCS, který jsem použil.
  • SCCS - tak dávno si nepamatuji nic mimořádně dobrého nebo špatného.
  • RCS - jak poukazovali ostatní, raději by sali zpocené oslí koule.
  • CVS - byla to jen bolest při použití s ​​více než 2 programátory. nejlepší funkce: rcs2cvs.
  • VSS - funguje to, kromě úterý, kdy poškozuje celé úložiště.
  • Perforce - stojí víc než moje auto. Samotný VCS je přijatelný, ale ten chlapík IT, který ovládá všechny aspekty jeho používání, ho nikdy nepřistane na mém „preferovaném“ seznamu.
  • SVN - větvení a slučování je fena, ale obecně je lepší než kterákoli z předchozích. Není to tak dobré, se spoustou drobných výjimečných změn čekajících na kontrolu.
  • Mercurial - jaké malé zkušenosti s tím mám, mám rád. Mohl bych to zkusit na svém dalším projektu.
  • Git - nikdy neměl příležitost ji použít.

Ačkoli pár byl hrůzou, většina z nich byla „v pořádku“. Nedokázali mi bránit. Dokud nástroj --- (neztěžuje mi život podstatně obtížněji, nevadí mi to.

Skutečné je pochopit silné a slabé stránky každého z nich. Porozumět cílovému prostředí:

  • distribuované nebo místní
  • malý tým nebo velký
  • hostované služby Vcs nebo ne
  • snadná integrace do jiných nástrojů

Joel také vyšel s důležitým pozorováním: Naučte se nástroj a jeho skutečný model použití. Mocně se snažil přimět Mercurial, aby se choval jako Subversion.

4
brettmjohnson

Jeden novější systém, který používáme v mé kanceláři, je Plastic SCM (http://www.plasticscm.com/). Funguje to velmi dobře pro náš malý tým a dává nám velkou kontrolu nad všemi aspekty správy zdrojů.

2
Tom A

SCCS .

Nebo pokud jste náhodou nežili v jeskyni posledních 38 let, CSSC .

Vážně moje společnost používá TeamWare , což je druh pseudo DVCS založeného na SCCS.

Ne, nedělám si srandu.

Sun přešel na Mercurial z TeamWare teprve před několika lety. Nyní byste měli pochopit, proč Java vypadalo, že se pohybuje tak pomalu.

1
Geoffrey Zheng

MPW: No, nemohu to opravdu udělat recenzi navzdory mému úsilí.

To bylo zpět, když jsem se učil programování na střední škole, a jediný skutečně volný kompilátor C++, který měl být, byl Macintosh Programming Workbench, který jsem držel na zipovém disku a vrhl se do toho, co byla v laboratoři k dispozici Performa.

MPW přišel s desítkami nástrojů (žádný z nich nebyl resedit, to bylo samostatné stahování), a jedním z nich byl obslužný program pro správu verzí. Otevřelo malé okno s jediným řádkem textu a měli jste na něj přetáhnout své projekty nebo soubory. Neměl žádnou dokumentaci, kterou jsem kdy objevil, neobvyklé vzhledem k tomu, že všechno ostatní vypadalo, že má skvělé dokumenty, a tak jsem nikdy docela nepřišel na to, jak je použít.

To byl můj první kartáč s VC a ten poslední na dlouhou dobu. Nyní používám git na všechno.

RCS - Revision Control System

Sólové kódování je tak snadné.

0
Jé Queue

Použil jsem Visual SourceSafe a nenáviděl jsem to, ale bylo to lepší než nic, ale ne moc. Za posledních pár let používal něco, co Qumasoft.com nazývalo QCVS, napsané, vlastněné a podporované programátorem Jimem Vorisem. Jednoduché gui, levná cena, dobrá podpora.

Jen dělá svou práci.

0
crosenblum

Není to ClearCase, přinejmenším pro systém Unix/Linux (možná u Windows je instalační program jednodušší). Bylo pro mě snazší naučit se nový nástroj, Perforce, než upgradovat náš server ClearCase.

Momentálně používám Perforce v práci a líbí se mi to, ale netuším, jestli je to nejlepší. Nastavení prostředí příkazového řádku a serveru Perforce je trochu nepříjemné, ale používání vizuálního klienta je poměrně snadné. Rád si myslím, že uživatelé mají s ním docela snadný čas na každodenní úkoly; je to jen počáteční nastavení vyžaduje nějakou práci.

0
Chance