Me and Version Control Tools

Oorspronkelijk geschreven op 02/11/2017 - 22:46

Omdat ik ook thuis een verstandig programmeur probeer te zijn, gebruik ik een versiebeheer hulpmiddel. Het leek me logisch dat als ik met Python werk dat ik dan ook een in Python gebouwd VCS (Version Control System) gebruik maar dat blijkt niet per se het geval, veel Python ontwikkelaars en zelfs Python zelf gebruiken Git. Toch gebruik ik Mercurial. En dus ook BitBucket, omdat ik m'n werkjes misschien ook wel eens aan iemand wil laten zien als ik m'n laptop niet bij me heb.

Momenteel werk ik met drie repositories (plekken waar de code staat): twee lokaal en één op BitBucket (een hosting site voor software projecten en een van de weinige  - voor zover ik weet - waar je met Mercurial terecht kan).

Het begint in een ontwikkel repository waarin de programma's staan waaraan ik werk en die ik ook dagelijks gebruik zodat ik direct voor m'n kiezen krijg wat ik nou weer verprutst heb (valt reuze mee overigens). Als het goed is zorg ik regelmatig dat wat ik doe vastgelegd wordt in de versiedata, zodat ik makkelijk terug kan als ik een fout maak die ik niet makkelijk kan fixen of als ik niet tevreden ben. Ik noem dat mijn "working" repository.

Op gezette tijden (liefst dagelijks maar zolang ik dat nog niet geautomatiseerd heb komt het daar niet altijd van) zet ik wat ik klaar heb over naar de "centrale" repository die overigens nog steeds lokaal staat, dit is een soort tussenstation dat het mogelijk maakt om als ik tegelijkertijd aan iets anders wil werken dat te doen in een (tijdelijk) extra repository die ik op dat moment van de centrale kan klonen. Wanneer dat nuttig of nodig is ook kan ik deze terug laten integreren in de "centrale" en datgene waar ik apart aan ben gaan werken kan ik desgewenst weer binnenhalen in de "working" repo. Niet dat ik dat al eens gedaan heb, maar het is mogelijk en dat is een prettig idee. Open source projecten werken in werkelijkheid echt zo.

Doorgaans tegelijkertijd (want dat is wel zo makkelijk en dan hoef ik er niet apart aan te denken) zet ik het spul ook door naar BitBucket. Als het daar staat heb ik mezelf echt voor de hele wereld te kijk gezet dus dan ben ik er kennelijk tevreden genoeg over dat ik dat aandurf... maar het belangrijkste is toch dat ik het dan niet zomaar kwijt ben.

Wij stoere codekloppers doen dat natuurlijk allemaal met losse commando's op de commandoregel (hg commit, hg push etcetera) maar het is toch een heleboel werk bij elkaar. Je bent geen echte programmeur als je je dat niet makkelijker probeert te maken en daarom heb ik met behulp van een Python library genaamd  fabric  een scriptje gemaakt dat een en ander automatiseert door alle repositories af te schuimen om te kijken wat daar moet gebeuren (de status ophaalt met andere woorden) en daarover rapporteert zodat ik een overzicht krijg waar nog wat in te checken valt en waar migreren naar de volgende repository aan de beurt is - want idealiter doe je dat regelmatig maar de realiteit is dat het er niet altijd van komt. Zo'n overzicht ziet er bijvoorbeeld zo uit:

console output of checking all repo changes

Waar "outgoing changes" staat kan met hetzelfde script met een andere optie nogmaals draaien de code overgezet worden naar een volgende repository; staat er "uncommitted changes" dan moet ik naar de repository toe om de code eerst in te checken. Zoals ik eerder al schreef wil je dat het liefst zo vaak mogelijk doen - de code hoeft nog niet eens goed te zijn maar dan heb je je wijzigingen in elk geval bewaard zodat je wat je daarna verprutst weer gemakkelijk ongedaan kunt maken. Maar je moet wel elke afzonderlijke repository in om de wjzigingen te bekijken en er iets mee te doen, allemaal met apparte commando's en ook dat moet toch makkelijker kunnen zou je zeggen. Dus heb ik maar weer een tooltje gemaakt waarmee ik vanuit een centrale plaats in een repository diverse veelgebruikte commando's kan uitvoeren:

showing the screen of my check-repo tool

Op deze manier kan ik vanuit dezelfde plek snel achter elkaar de repos waar wat aan de hand is inspecteren en eventueel doen wat daar gedaan moet worden. Niet alles weliswaar, maar als het ingewikkelder wordt moet ik toch even rustig kijken wat er aan de hand is.

Terugkomend op Mercurial versus Git: in bovengenoemde tooling draait inmiddels ook één git repository mee omdat ik vond dat ik daar toch ok eens kennis mee moest maken (en ook al kun je op BitBucket ook git-repositories gebruiken, ik zit nu dus ook op GitHub) maar het voelt toch ongemakkelijk om mee te werken. Geen idee waarom, zal toch wel zijn omdat ik inmiddels al zo aan Hg (afkorting voor Mercurial) gewend ben.

Trefwoorden: programming, versiebeheer