Vaak wanneer ik aan het ontwikkelen ben begin ik eerst lokaal met een klein project. Deze groeit uiteindelijk uit in een iets groter project waar nog wat wijzigingen in plaatsvinden en uiteindelijk wordt het dan het product wat je voor ogen had. Tijdens deze ontwikkeling wil ik dan wel altijd versiebeheer hebben, zodat alles geborgd is.

Voor m’n prive projecten gebruik ik inmiddels al een tijdje Mercurial en ben daar ook enorm tevreden over. Zeker met de plug-ins welke voor Visual Studio worden aangeboden is het goed werken en heb je de hele commandline bijna niet meer nodig.

Wat ik wel vervelend vond is dat het me nog niet was gelukt om een lokale repository te verplaatsen naar een centrale repository en die dan leading maken.

Met het commando hg clone of hg push kon ik het m’n centrale server krijgen, maar dan bleef m’n lokale repository leading en dat moet natuurlijk andersom. Na een kleine speurtocht ben ik er achter gekomen dat de leading repository wordt bijgehouden in het bestand hgrc (pad is .hg/hgrc). Hier staat een entry in met het pad naar de centrale repository. Door deze aan te passen kun je dus de lokale waarde wijzigen in de centrale.

Zoals is te lezen heb ik gekozen om Mercurial te gaan gebruiken als versiebeheer systeem voor eigen code.
Na installatie had ik al vrij snel een nieuwe repository gemaakt met daarin m’n code. Je start gewoon de command prompt op, gaat naar de map welke in het versiebeheer systeem moet komen. Tikt het volgende in:

hg init
hg add
hg com -m "Initial commit"

3 commando’s, dat is alles wat gedaan moet worden om je code in een nieuwe repository te plaatsen. Een redelijk goede guide is hier te vinden: https://mercurial.selenic.com/guide/

Omdat ik niet heel bekend was/ben met DVCS systemen heb ik eerst het een en ander ingelezen over de werking en wat de bedoeling precies is. Voor Mercurial is er een super goede tutorial geschreven door Joel Spolsky op https://hginit.com/. Hier heb ik veel informative vandaan gehaald over hoe ik moet werken met Mercurial.

Ook het hosten van je code op een server is enorm eenvoudig. In je repository tik je het volgende hg serve

Zodra dat is gedaan zal je repository gelijk op poort 8000 zijn te bereiken, dus bijvoorbeeld https://localhost:8000/. Hier was ik heel blij mee.

Toen ik klaar was om m’n repository te vullen met m’n projecten kwam ik toch een beetje bedrogen uit. Blijkbaar is het niet de bedoeling om verschillende solutions, verspreid over meerdere locaties op je systeem, in 1 repository op te slaan. Voor iedere solution is het dus van belang om een nieuwe repository te maken wanneer deze niet op 1 locatie staan. Dit gooide een beetje roet in het eten, aangezien ik had verwacht dat dit wel de bedoeling was.
Gelukkig kun je met het hg serve commando via een argument opgeven op welke poort deze dient te draaien, waardoor het mogelijk is om meer dan een repository te hosten op je systeem. Dit vond ik zelf niet een enorm fijne oplossing, maar als het niet anders kan, dan is het zo. Als hier geen alternatief voor zou zijn geweest, dan was ik waarschijnlijk weer overgestapt op een ander systeem. Gelukkig heeft Jeremy Skinner op z’n weblog gepost hoe je meerdere repositories op je Windows Server kan hosten (https://www.jeremyskinner.co.uk/mercurial-on-iis7/).
Deze tutorial heb ik dan ook stap voor stap gevolgd. Enige punt waar ik tegen aanliep was dat hij schrijft over de hgwebdir.cgi, maar die kon ik niet vinden in mijn versie van Mercurial, hier heb ik dan ook hgweb.cgi gebruikt. Deze lijkt ook prima te werken. Door het volgen van deze hele visuele tutorial heb ik nu een werkende Mercurial webserver met al m’n solutions in verschillende repositories.

Onlangs ben ik op zoek gegaan naar een beter versiebeheer system voor m’n hobby- en Vinit projecten. Zelf ben ik altijd behoorlijk tevreden geweest over Visual SourceSafe van Microsoft, hoewel niet iedereen die mening deelt (Coding Horror & High Programmer) Zelf ben ik van mening dat zo lang iets voldoet aan de eisen en wensen die je hebt dat het goed genoeg is.

Omdat SourceSafe toch wel oud begint te worden ben ik vorig jaar eens gaan kijken naar Subversion (SVN), omdat iedereen daar wel enthousiast over is/was. Na enkele projecten in SVN te hebben gezet lijkt het inderdaad wel een prima vervanger. Nadeel dat ik ondervond was dat het browsen in de verkenner enorm werd vertraagd. Tevens heb ik nogal eens ruzie bij het verwijderen, verplaatsen of hernoemen van bestanden. Dit zal allemaal vast kunnen worden ingesteld en in de handleiding staat vast ook goed uitgelegd hoe je met SVN moet werken, maar dat heb ik allemaal niet gedaan. Nog een nadeel van SVN vind ik dat in iedere map een .svn-map wordt aangemaakt. Door al deze nadelen is SVN geen geschikte keus voor versiebeheer systeem voor mij.

Op het werk gebruik ik graag Team Foundation Server (TFS) van Microsoft. Dit is een prachtig pakket, enorm uitgebreid, waardoor er een heel team mee kan werken van ontwikkelaar tot tester tot project manager. Voor mij is hier het grootste nadeel dat het (veel) geld kost. Voor een middel grote organisatie is het een klein bedrag als je kijkt wat je er voor terug krijgt, maar het is te veel voor mijn portemonee. Tevens zijn de systeem eisen redelijk hoog, zeker als je alleen maar het versiebeheer gedeelte van TFS wilt gaan gebruiken. Dan heb je eigenlijk een tank om een mug dood te schieten. Jammergenoeg valt TFS dus ook af.