Hoe ik werk: Mercurial (Hg)

Oorspronkelijk geschreven op 21/05/2011

Kort geleden was op comp.lang.python een topic over versie controle systemen. Naar aanleiding daarvan ben ik toen ook naar Bazaar en met name Fossil gaan kijken. Git kwam ook langs, maar dat lijkt volgens zeggen zoveel op Hg - en dat gebruikte ik al - dat ik die even heb laten zitten.

Een van de dingen waar het over ging was wat je er als alleenstaand programmamaker aan zou kunnen hebben om aan versie controle te doen en de tendens van de discussie was: al heb je er niks aan, gebruik het gewoon, op een gegeven moment kom je vanzelf een keer tegen dat je denkt "goed dat ik er toch maar mee ben gaan werken".

Zelf was ik er vorig jaar of zo al eens achter gekomen dat het wel handig was als ik een makkelijke manier had om het (om)bouwen van een programma af te breken en opnieuw te beginnen met een vorige versie. Daarvoor had ik eerst zelf wat gemaakt [*] maar na een poosje ermee werken ben ik toch maar eens naar een bestaand systeem gaan kijken en dat beviel wel.

Ik heb mezelf de volgende manier van werken aangewend: ergens - in dit geval op mijn laptop - heb ik een "centrale versie" van de repositories staan, die ook gekoppeld is aan een webserver (die overigens alleen via het thuisnetwerk te benaderen is) en aan Trac.

De productieversie van een project is een lokale versie van de centrale repository, waar ik naar hartelust op pruts om aanpassingen en verbeteringen te doen. Elke machine waar ik op werk (mijn laptop, een desktop thuis, mijn usb stick, mijn werk pc waar ik mijn eigen tools op heb staan) heeft zo'n lokale versie, die in principe gekloond is van de centrale versie (die op mijn werk pc is gekloond van de versie op mijn usb stick).

Ontwikkelen op de productieversie in in allerlei omgevingen taboe maar ik doe het lekker wel, ik ben tenslotte de baas en niet een of ander principe van "zo hoort het". Dat soort principes zijn prima maar je moet ze wel met gezond verstand gebruiken. En ik vind het voor m'n eigen tools makkelijker om niet eerst een testomgevinkje op te hoeven tuigen, daar dingen op te doen, die dan te integreren in mijn werkomgeving en dat dan weer te pushen naar de centrale versie. Dat is me één stap die ik net zo goed weg kan laten te ver.

Dat gaat natuurlijk alleen maar op voor de dingen die ik voor mezelf doe. Ik ben er op het werk genoeg tegen aan gelopen dat ontwikkelen op de productieversie van tools die ook door anderen gebruikt worden niet zo'n goed idee is.

Eén ding is zeker: van het nut van een versiebeheersysteem hoef je mij niet meer te overtuigen...

[*]Wat dit ding deed was het volgende: als je de opdracht gaf om een programmacomponent (source) te "versioneren" dan kon je een omschrijving/reden opgeven en dan werd het op een centrale plek neergezet met datum/tijd toegevoegd in de bestandsnaam. Omschrijving, oorspronkelijke en aangepaste bestandsnaam werden daarbij opgenomen in een SQLite database zodat je de geschiedenis van een component kon bekijken. daarvoor was natuurlijk wat configuratie nodig (componentversies van welk project worden in welke directory opgeslagen) en daarvoor ben ik toen een projectenregistratie-GUI wezen bouwen met het idee die dan weer in DocTool op te gaan nemen - wat op een bepaalde manier ook wel weer gelukt is maar dan door een link naar de centrale mercurial repository op te nemen.

Trefwoorden: programmeren, organiseren, versiebeheer