Ik heb al een tijdje git gebruikt op Windows (met MSYGIT) en ik hou van het idee van gedistribueerde broncontrole. Onlangs heb ik bekeken naar Mercurial (HG) en het ziet er interessant uit. Ik kan echter niet mijn hoofd omwikkelen rond de verschillen tussen HG en Git.
Heeft iemand een side-by-side-vergelijking gemaakt tussen Git en HG? Ik ben geïnteresseerd om te weten wat HG en GIT verschilt zonder in een fanboy-discussie te hoeven springen.
Antwoord 1, Autoriteit 100%
Deze artikelen kunnen helpen:
- git vs. Mercurial: Gelieve te ontspannen (git is MacGyver en Mercurial is James Bond)
- De verschillen tussen Mercurial en Git
bewerken : het vergelijken van Git en Mercurial to Beroemdheden lijkt een trend te zijn. Hier is nog een:
Antwoord 2, Autoriteit 69%
Ik werk op Mercurial, maar fundamenteel geloof ik dat beide systemen gelijkwaardig zijn. Ze werken allebei met dezelfde abstracties: een reeks snapshots (wijzigingen) die de geschiedenis vormen. Elke wijzigingenet weet waar het vandaan kwam (de bovenliggende wijzigingen = en kan veel kinderschakels krijgen. De recente HG-git extension biedt een tweerichtingsbrug tussen Mercurial en Git en Sort of Shows dit punt .
Git heeft een sterke focus op het monteren van deze geschiedenisgrafiek (met alle gevolgen die met zich meebrengt) terwijl Mercurial de geschiedenis niet aanmoedigt herschrijven, Maar het is gemakkelijk om te doen hoe dan ook en de gevolgen hiervan zijn precies wat u zou moeten verwachten dat ze zijn (dat is, als ik een wijzigingen aan wijzen die u al hebt, zal uw cliënt het als Nieuw als je aan mij trekt). Dus Mercurial heeft een bias naar niet-destructieve commando’s.
Wat betreft lichtgewicht takken, dan heeft Mercurial repositories ondersteund met meerdere takken sinds …, altijd denk ik. Git-repositories met meerdere takken zijn precies dat: meerdere uiteenlopende strengen in een enkele repository. Git voegt vervolgens namen toe aan deze strengen en laat u deze namen op afstand vragen. The bladwijzers extensie voor Mercurial voegt lokale namen toe, en met Mercurial 1.6 kunt u deze bladwijzers verplaatsen rond wanneer je duwt / trekt ..
Ik gebruik Linux, maar blijkbaar is Tortoisehg sneller en beter dan het git-equivalent op Windows (vanwege een beter gebruik van het slechte Windows-bestandssysteem). Beide http://github.com en http://bitbucket.org bieden online hosting, de service bij Bitbucket is geweldig en responsief (ik heb geen github geprobeerd).
Ik heb Mercurial gekozen omdat het schoon en elegant voelt – ik werd uitgesteld door de Shell / Perl / Ruby-scripts die ik met Git kreeg. Probeer een kijkje te nemen op de git-instaweb.shBestand Als u wilt weten wat ik bedoel: het is een shell script dat een Ruby script genereert, waarvan ik denk dat een webserver wordt uitgevoerd. Het Shell-script genereert een ander shell-script om het eerste Ruby-script te starten. Er is ook een beetje perl , voor een goede maatregel.
Ik hou van de blogpost vergelijkt Mercurial en Git met James Bond en MacGyver – Mercurial is op de een of andere manier low-key dan Git. Het lijkt mij, dat mensen die Mercurial gebruiken niet zo gemakkelijk onder de indruk zijn. Dit wordt weerspiegeld in hoe elk systeem doet welke linus wordt beschreven als “de coolste Samenvoegen ooit! “. In Git kunt u samenvoegen met een niet-gerelateerde repository door:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Die commando’s zien er vrij arcaan in mijn oog. In Mercurial doen we:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Merk op hoe de Mercurial-commando’s duidelijk zijn en helemaal niet speciaal — het enige ongebruikelijke is de --forcevlag om hg pullte gebruiken, die nodig is sinds Mercurial zal anders afbreken wanneer u uit een niet-gerelateerde repository haalt. Door dit soort verschillen lijkt Mercurial me eleganter.
Antwoord 3, autoriteit 21%
Git is een platform, Mercurial is “slechts” een applicatie. Git is een bestandssysteemplatform met versiebeheer dat toevallig wordt geleverd met een DVCS-app in de doos, maar zoals normaal voor platform-apps, is het complexer en heeft het ruwere randen dan gerichte apps. Maar dit betekent ook dat git’s VCS enorm flexibel is, en er is een enorme hoeveelheid niet-bron-control dingen die je met git kunt doen.
Dat is de essentie van het verschil.
Git wordt het best vanaf het begin begrepen – vanaf het repository-formaat. Scott Chacon’s Git Talkis hiervoor een uitstekende inleiding. Als je git probeert te gebruiken zonder te weten wat er onder de motorkap gebeurt, zul je op een gegeven moment in de war raken (tenzij je je aan slechts zeer basisfunctionaliteit houdt). Dit klinkt misschien stom als je alleen maar een DVCS wilt voor je dagelijkse programmeerroutine, maar het geniale van git is dat het repository-formaat eigenlijk heel eenvoudig is en je kuntde hele operatie van git vrij gemakkelijk begrijpen.
Voor wat meer technische vergelijkingen zijn de beste artikelen die ik persoonlijk heb gezien, de artikelen van Dustin Sallings:
- De verschillen tussen Mercurial en Git
- Reddit-thread waarin git-ervaren Dustin zijn eigen git-neophyte-vragen beantwoordt
Hij heeft beide DVCS’s uitgebreid gebruikt en begrijpt ze allebei goed – en gaf uiteindelijk de voorkeur aan git.
Antwoord 4, autoriteit 15%
Het grote verschil zit in Windows. Mercurial wordt standaard ondersteund, Git niet. U kunt zeer vergelijkbare hosting krijgen als github.commet bitbucket.org(eigenlijk zelfs beter omdat je een gratis privé-repository krijgt). Ik gebruikte msysGit al een tijdje, maar ben overgestapt naar Mercurial en ben er erg blij mee.
Antwoord 5, autoriteit 11%
Als u een Windows-ontwikkelaar bent die op zoek is naar eenvoudig niet-verbonden revisiebeheer, ga dan met Hg. Ik vond Git onbegrijpelijk, terwijl Hg eenvoudig was en goed geïntegreerd met de Windows-shell. Ik heb Hg gedownload en deze tutorial (hginit.com)gevolgd – tien minuten later had ik een lokale repo en was weer aan het werk op mijn project.
Antwoord 6, autoriteit 6%
Ik denk dat de beste beschrijving van “Mercurial vs. Git” is:
“Git is Wesley Snipes. Mercurial is Denzel Washington”
Antwoord 7, autoriteit 6%
Ze zijn bijna identiek.
Het belangrijkste verschil, vanuit mijn oogpunt (ik bedoel, de reden waarom ik de ene DVCS heb gekozen boven de andere) is hoe de twee programma’s filialen beheren.
Om met Mercurial een nieuwe branch te starten, kloon je de repository naar een andere directoryen begin je met ontwikkelen. Dan trek je en voeg je samen.
Met Git moet u expliciet een naam geven aan de nieuwe onderwerptak die u wilt gebruiken, dan begint u te coderen met behulp van dezelfde map .
Kortom, elke filiaal in Mercurial heeft zijn eigen map nodig; In Git werk je meestal in een enkele directory.
Schakelende takken in Mercurial betekent veranderende mappen; In Git betekent het om Git te vragen de inhoud van de map met Git Checkout te wijzigen.
Ik ben eerlijk: ik weet niet of het mogelijk is om hetzelfde te doen met Mercurial, maar aangezien ik meestal aan webprojecten werk, het gebruik van altijd dezelfde map met git met Git veel comfortabel voor mij lijkt moet Apache opnieuw configureren en het opnieuw opstarten en ik rotzooi mijn bestandssysteem niet telkens als ik tak.
EDIT: Zoals Deestan heeft opgemerkt, heeft HG genoemde takken , die in een enkele repository kunnen worden opgeslagen en de ontwikkelaar toestaan om takken binnen dezelfde werkkopie te schakelen. Git-vestigingen zijn niet precies hetzelfde als Mercurial genaamd takken, hoe dan ook: ze zijn permanent en gooi takken niet weg, zoals in Git. Dat betekent dat als u een genoemde tak gebruikt voor experimentele taken, zelfs als u besluit nooit samen te voegen, zal het in de repository worden opgeslagen. Dat is de reden waarom HG stimuleert om klonen te gebruiken voor experimentele, kortlopende taken en genoemde takken voor langdurige taken, zoals voor release-takken.
De reden waarom veel HG-gebruikers prefereer klonen over de naam van de naam veel sociaal of cultureel dan technisch. Bijvoorbeeld, met laatste versies van HG, het is zelfs mogelijk om een genoemde tak te sluiten en wordt het recursief verwijderen metadata van wijzigingen.
Aan de andere kant nodigt GIT uit om “genoemde takken” te gebruiken die niet permanent zijn en niet als metadata op elke wijzigingen worden opgeslagen.
Vanuit mijn persoonlijk oogpunt is het model van git dus nauw verbonden met het concept van benoemde branches en schakelen tussen een branch en een andere binnen dezelfde directory; hg kan hetzelfde doen met benoemde branches, maar toch moedigt het het gebruik van klonen aan, wat ik persoonlijk niet zo leuk vind.
Antwoord 8, autoriteit 5%
Er is één grootverschil tussen giten mercurial; de manier waarop ze elke commit vertegenwoordigen. gitvertegenwoordigt commits als snapshots, terwijl mercurialze vertegenwoordigt als diffs.
Wat betekent dit in de praktijk? Nou, veel operaties zijn sneller in git, zoals overschakelen naar een andere commit, commits vergelijken, enz. Vooral als deze commits ver weg zijn.
AFAIK heeft geen voordeel van de benadering van mercurial.
Antwoord 9, autoriteit 3%
Niets. Ze doen allebei hetzelfde, ze presteren allebei ongeveer even goed. De enige reden waarom je de ene boven de andere zou moeten kiezen, is als je meehelpt aan een project dat er al een gebruikt.
De andere mogelijke reden om er een te kiezen is een applicatie of service die slechts één van de systemen ondersteunt.. Ik koos er bijvoorbeeld min of meer voor om git te leren vanwege github..
Antwoord 10, autoriteit 3%
Ook de vergelijking van Google (hoewel het een beetje oud is, gedaan in 2008)
http://code.google.com/p/support/wiki/DVCSAnalysis
Antwoord 11, autoriteit 3%
Als ik ze goed begrijp (en ik ben verre van een expert op elk gebied), hebben ze in wezen elk een andere filosofie. Ik heb eerst 9 maanden mercurial gebruikt. Nu heb ik git voor 6 gebruikt.
hg is software voor versiebeheer. Het belangrijkste doel is om versies van een stuk software bij te houden.
Git is een op tijd gebaseerd bestandssysteem. Het doel is om een andere dimensie toe te voegen aan een bestandssysteem. De meeste hebben bestanden en mappen, Git voegt tijd toe. Dat het gebeurt om geweldig te werken als een VCS is een bijproduct van het ontwerp.
In HG is er een geschiedenis van het hele project dat het altijd probeert te onderhouden. Standaard geloof ik dat HG alle veranderingen in alle objecten door alle gebruikers wenst bij het duwen en trekken.
In Git is er slechts een pool van objecten en deze tracking-bestanden (filialen / hoofden) die bepalen welke set van die objecten de boom van bestanden in een bepaalde staat vertegenwoordigen. Bij het duwen of trekken Git verzendt alleen de objecten die nodig zijn voor de specifieke takken die u duwt of trekken, wat een kleine subset van alle objecten is.
Wat Git betreft is er geen “1 project”. Je zou 50 projecten kunnen hebben in dezelfde repo en git zou het niet schelen. Iedereen kan afzonderlijk in dezelfde repo worden beheerd en prima.
Het concept van takken van HG is takken van het hoofdproject of takken van takken enz. Git heeft geen dergelijk concept. Een tak in Git is slechts een staat van de boom, alles is een tak in Git. Welke tak is officieel, de huidige of nieuwste heeft geen betekenis in Git.
Ik weet niet of dat enige zin heeft gemaakt. Als ik foto’s kon tekenen, kan HG er als volgt uitzien waar elke commit een o
is
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
een boom met een enkele wortel en takken die ervan uitkomen. Terwijl Git dat kan doen en vaak gebruiken mensen het op die manier die niet afgedwongen is. Een git-afbeelding, als er zoiets is, kan gemakkelijk er als volgt uitzien
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
In feite is het in sommige opzichten niet eens logisch om takken in Git te tonen.
Eén ding dat erg verwarrend is voor de discussie, git en mercurial hebben beide iets dat een “branch” wordt genoemd, maar het zijn in de verste verte niet dezelfde dingen. Een branch in mercurial ontstaat wanneer er conflicten zijn tussen verschillende repo’s. Een branch in git lijkt blijkbaar op een kloon in hg. Maar een kloon, hoewel het soortgelijk gedrag kan geven, is zeker niet hetzelfde. Overweeg me deze te proberen in git vs hg met behulp van de chroomrepo die vrij groot is.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
En nu in hg met kloon
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Beide zijn hot runs. Dat wil zeggen, ik heb ze twee keer gelopen en dit is de tweede keer. hg clone is eigenlijk hetzelfde als git-new-workdir. Beide maken een geheel nieuwe werkmap, bijna alsof je cp -r project project-clonehebt getypt. Dat is niet hetzelfde als een nieuwe branch maken in git. Het is veel zwaarder. Als er een echt equivalent is van de vertakking van git in hg, weet ik niet wat het is.
Ik begrijp op een bepaald niveau hg en git misschienkan soortgelijke dingen doen. Als dat zo is, is er nog steeds een enorm verschil in de workflow waar ze je naartoe leiden. In git is de typische workflow om voor elke functie een vertakking te maken.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Dat heeft zojuist 3 branches gemaakt, elk gebaseerd op een branch genaamd master.
(Ik weet zeker dat er een manier is in git om die 1 regel elk te maken in plaats van 2)
Nu werken aan een die ik gewoon doe
git checkout fix-game-save-bug
en ga aan het werk. Commit dingen, enz. Schakelen tussen branches, zelfs in een project zo groot als chrome is bijna onmiddellijk. Ik weet eigenlijk niet hoe ik dat in hg moet doen. Het maakt geen deel uit van de tutorials die ik heb gelezen.
Nog een groot verschil. Gits podium.
Git heeft het idee van een podium. Je kunt het zien als een verborgen map. Als je commit, commit je alleen wat er op het podium staat, niet de veranderingen in je werkboom. Dat klinkt misschien vreemd. Als je alle wijzigingen in je werkboom wilt vastleggen, doe je git commit -adie alle gewijzigde bestanden aan de stage toevoegt en ze vervolgens vastlegt.
Wat is het nut van het podium dan? Je kunt je commits gemakkelijk scheiden. Stel je voor dat je joypad.cpp en gamesave.cpp hebt bewerkt en je wilt ze afzonderlijk vastleggen
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git heeft zelfs commando’s om te beslissen welke specifieke regels in hetzelfde bestand je naar de stage wilt kopiëren, zodat je die commits ook apart kunt opsplitsen. Waarom zou je dat willen doen? Omdat als afzonderlijke commits anderen alleen degene kunnen trekken die ze willen of als er een probleem was, kunnen ze alleen de commit terugdraaien die het probleem had.
Antwoord 12, autoriteit 2%
Er is een dynamische vergelijkingstabel op de versioncontrolblog waar je verschillende versiebeheersystemen kunt vergelijken.
Hier is een vergelijkingstabel tussen git, hg en bzr.
Antwoord 13, autoriteit 2%
Er zijn behoorlijk grote verschillen als het gaat om het werken met filialen (vooral voor korte termijn).
Het wordt uitgelegd in dit artikel (BranchingExplained)waarin Mercurial wordt vergeleken met Git.
p>
Antwoord 14, autoriteit 2%
Zijn er op Windows gebaseerde medewerkers aan uw project?
Omdat als die er zijn, de Git-for-Windows GUI onhandig, moeilijk en onvriendelijk lijkt.
Mercurial-on-Windows daarentegen is een no-brainer.
Antwoord 15, autoriteit 2%
Eén ding om op te merken tussen mercurial van bitbucket.org en git van github is dat mercurial zoveel privé-repositories kan hebben als je wilt, maar github moet je upgraden naar een betaald account. Dus daarom ga ik voor bitbucket dat mercurial gebruikt.
Antwoord 16
Ergens vorig jaar evalueerde ik zowel git als hg voor mijn eigen gebruik, en besloot om voor hg te gaan. Ik vond dat het op een schonere oplossing leek en op dat moment beter werkte op meer platforms. Het was echter meestal een opgooi.
Meer recentelijk ben ik git gaan gebruiken vanwege git-svn en de mogelijkheid om op te treden als een Subversion-client. Dit heeft me overtuigd en ik ben nu volledig overgestapt op git. Ik denk dat het een iets hogere leercurve heeft (vooral als je de binnenkant moet doorzoeken), maar het is echt een geweldig systeem. Ik ga die twee vergelijkingsartikelen lezen die John nu heeft gepost.
Antwoord 17
Ik ben momenteel bezig met het migreren van SVN naar een DVCS (terwijl ik blog over mijn bevindingen, mijn eerste echte blogpoging…), en ik heb wat onderzoek gedaan (=googlen). Voor zover ik kan zien kun je met beide pakketten de meeste dingen doen. Het lijkt erop dat git een paar meer of beter geïmplementeerde geavanceerde functies heeft,
Ik heb het gevoel dat de integratie met Windows een beetje beter is voor Mercurial, met Tortoisehg. Ik weet dat er ook Git Cheetah is (ik heb beide geprobeerd), maar de Mercurial-oplossing voelt alleen robuuster.
Zien hoe ze beide open-source zijn (toch?) Ik denk niet dat ofwel geen belangrijke functies zal ontbreken. Als iets belangrijks is, zullen mensen erom vragen, mensen zullen het coderen.
Ik denk dat voor gemeenschappelijke praktijken, Git en Mercurial meer dan voldoende zijn. Ze hebben allebei grote projecten die ze gebruiken (Git – & GT; Linux Kernel, Mercurial – & GT; Mozilla Foundation Projects, beide onder andere natuurlijk), dus ik denk niet dat ofwel niet iets ontbreekt.
Dat gezegd hebbende, ik ben geïnteresseerd in wat andere mensen hierover zeggen, omdat het een geweldige bron zou maken voor mijn bloginspanningen; -)
Antwoord 18
Er is een geweldige en uitputtende vergelijkingstabellen en grafieken op Git, Mercurial en Bazaar bij infoq’s Gids over DVC’s .
Antwoord 19
Ik realiseer me dat dit geen deel uitmaakt van het antwoord, maar in die notitie denk ik ook dat de beschikbaarheid van stabiele plug-ins voor platforms zoals NetBeans en Eclipse een rol spelen in welke tool een betere pasvorm is voor de taak, of liever , welke tool is de beste pasvorm voor “u”. Dat wil zeggen, tenzij u echt wilt doen, wil het de CLI-Way doen.
Zowel Eclipse (en alles op basis van IT) en netbeans hebben soms problemen met externe bestandssystemen (zoals SSH) en externe updates van bestanden; Dat is nog een andere reden waarom je wilt wat je ervoor kiest om “naadloos” te werken.
Ik probeer deze vraag nu ook voor mezelf te beantwoorden .. en ik heb de kandidaten ingekookt naar Git of Mercurial .. Bedankt allemaal voor het leveren van nuttige inputs op dit onderwerp zonder religieus te worden.
Antwoord 20
Nog een interessante vergelijking van mercurial en git: Mercurial vs Git .
De belangrijkste focus ligt op internals en hun invloed op het vertakkingsproces.
Antwoord 21
Als je geïnteresseerd bent in een prestatievergelijking van Mercurial en Git, bekijk dan dit artikel. De conclusie is:
Git en Mercurial draaien allebei in goede cijfers, maar maken een interessante afweging tussen snelheid en repositorygrootte. Mercurial is snel met zowel toevoegingen als wijzigingen, en houdt tegelijkertijd de groei van de repository onder controle. Git is ook snel, maar de repository groeit erg snel met gewijzigde bestanden totdat je het opnieuw inpakt – en dat opnieuw inpakken kan erg traag zijn. Maar de volgepakte opslagplaats is veel kleiner dan die van Mercurial.
Antwoord 22
De mercurial-website heeft een grote beschrijving van de overeenkomsten en verschillentussen de twee systemen, waarin wordt uitgelegd de verschillen in woordenschat en onderliggende concepten. Als een oude git-gebruiker, heeft het me echt geholpen om de Mercurial-mentaliteit te begrijpen.
Antwoord 23
Als u migreert vanuit SVN, gebruik dan Mercurial omdat de syntaxis VEEL begrijpelijker is voor SVN-gebruikers. Anders dan dat, kun je met beide niet fout gaan. Maar controleer de GIT-zelfstudieen HGinitvoordat je er een selecteert.
Antwoord 24
Deze link kan u helpen het verschil te begrijpen
http://www.techtatva.com/2010/ 09/git-mercurial-and-bazaar-a-comparison/
Antwoord 25
Sommige mensen denken dat VCS-systemen ingewikkeld moeten zijn. Ze moedigen het uitvinden van termen en concepten in het veld aan. Ze zouden waarschijnlijk denken dat tal van doctoraten over het onderwerp interessant zouden zijn. Onder hen zijn waarschijnlijk degenen die Git hebben ontworpen.
Mercurial is ontworpen met een andere mentaliteit. Ontwikkelaars zouden niet veel om VCS moeten geven, en in plaats daarvan zouden ze hun tijd moeten besteden aan hun hoofdfunctie: software-engineering. Mercurial stelt gebruikers in staat om het systeem te gebruiken en met plezier te misbruiken zonder dat ze onherstelbare fouten maken.
Elke professionele tool moet worden geleverd met een duidelijk ontworpen en intuïtieve CLI. Mercurial-gebruikers kunnen het meeste werk doen door eenvoudige opdrachten uit te voeren zonder vreemde opties. In Git double dash zijn gekke opties de norm. Mercurial heeft een aanzienlijk voordeel als je een CLI-persoon bent (en om eerlijk te zijn zou elke zichzelf respecterende Software Engineer dat moeten zijn).
Om een voorbeeld te geven, stel dat je per ongeluk een commit doet. U bent enkele bestanden vergeten te bewerken. Om uw actie in Mercurial ongedaan te maken, typt u gewoon:
$ hg rollback
Je krijgt dan een bericht dat het systeem je laatste transactie ongedaan maakt.
In Git moet je typen:
$ git reset --soft HEAD^
Dus oké, stel dat je een idee hebt waar reset over gaat. Maar daarnaast moet je weten wat “–soft” en “–hard” resets zijn (enige intuïtieve gissingen?). Oh en vergeet natuurlijk het ‘^’-teken op het einde niet! (wat is dat nu in Ritchie’s naam…)
Mercurial’s integratie met tools van derden zoals kdiff3 en meld is ook veel beter. Genereer je patches en voeg je branches samen zonder veel poespas. Mercurial bevat ook een eenvoudige http-server die u activeert door
. te typen
hg serve
En laat anderen door je repository bladeren.
Het komt erop neer dat Git doet wat Mercurial doet, op een veel gecompliceerdere manier en met een veel inferieure CLI. Gebruik Git als je van de VCS van je project een wetenschappelijk onderzoeksveld wilt maken. Gebruik Mercurial als u de VCS-klus wilt klaren zonder er veel om te geven, en u wilt concentreren op uw echte taken.