Inleiding
Programmacode kan men op verschillende manieren opslaan. Alleen op de harde schijf van een ontwikkelaar of op een netwerkschijf. Toch is dat niet handig als men er met verschillende mensen tegelijk aan werkt of wil werken. Versiebeheersystemen bieden hier een uitkomst. Dit klinkt logisch, maar worden deze systemen op een handige manier gebruikt? Dit artikel verhandelt wat algemene versiebeheerconcepten en de manier waarop CVS/SVN het meest gebruikt worden.

Systeemselectie
Er zijn talloze versiebeheersystemen verkrijgbaar. Dit artikel behandelt alleen de meest gangbare voor softwareontwikkeling (binnen bedrijven). Dat zijn CVS en Subversion, meestal afgekort tot SVN. CVS is een open source tool die al wat langer meegaat. Hoewel er veelvuldig gebruik van wordt gemaakt, wordt tegenwoordig toch vaak gemigreerd naar SVN. Laatstgenoemde is ook open source, komt uit 1999 en er wordt actief aan doorontwikkeld. SVN biedt veel extra features ten opzichte van CVS. Dit artikel vergelijkt niet alle verschillen, daarvoor is er onder andere een lijst met specificaties – handig in een tabel gezet – op Wikipedia

Concepten
Versiebeheersystemen worden vooral als opslagmedium voor code gebruikt. Het is een centrale plek die toegankelijk is vanaf verschillende locaties, omdat het via internet bereikbaar is. Dit is een goede start. Maar welke mogelijkheden zijn er nog meer?

Versiebeheer
Wat is eigenlijk een versie van een bestand? Meestal wordt hieronder een unieke identificatie verstaan, waarin de hele inhoud van een bestand is vastgelegd. Een bestand met een andere versie kan een andere inhoud hebben, terwijl een bestand met dezelfde versie exact dezelfde inhoud heeft. Hiermee wordt de inhoud vastgelegd of verzegeld.

Bestandsversie vs. programmaversie
Als men spreekt over ‘Windows XP’ of ‘Windows XP SP2 build 2023′, kan er nogal wat gewijzigd zijn tussen deze twee versies van Windows. De ontwikkeling gaat door, er worden nieuwe versies of wijzigingen uitgebracht die XP verbeteren of veiliger maken. Kortom, de ontwikkeling gaat door, terwijl er vastgelegd is welke versie de officiële Windows XP is. Dit gebeurt bij de meeste software. Dit proces wil je ook op deze manier kunnen vastleggen in een versiebeheersysteem. Deze systemen sluiten dan ook vaak aan op deze werkwijze.

Versies opslaan in CVS of SVN
Meestal kent men 3 verschillende manieren of locaties om versies op te slaan:

1. Trunk: dit is de plaats waar alle nieuwe ontwikkelingen worden doorgevoerd, tevens de bron waaruit of waarvan andere versies worden gemaakt.
2. Branch: dit is een afsplitsing (of aftakking) van de trunk, ofwel op een bepaald tijdstip is besloten om een kopie te maken van de ontwikkelversie om bijvoorbeeld hierop door te werken.
3. Tag: dit is een vastgelegde versie, waarop in principe niet wordt doorontwikkeld. Dit is met CVS technisch niet mogelijk, maar in SVN is een tag technisch hetzelfde als een branch.

In een typische softwareontwikkelomgeving wordt dit (waarschijnlijk) als volgt gebruikt: men begint te ontwikkelen en slaat de code op (ook wel committen geheten) in de trunk-omgeving. Ieder andere ontwikkelaar synchroniseert hiermee en commit zijn of haar eigen code hier. Dan besluit men richting een eerste versie van het product te gaan werken. Maar ondertussen moeten andere ontwikkelaars nog wel doorgaan met nieuwe grote wijzigingen in de code. Men besluit dan vaak om een branch te maken. Hier wordt de eerste release op gestabiliseerd en de fouten die gevonden worden, kunnen hier worden opgeslagen. De ontwikkelaars die reparaties doen aan de branch, moeten dit vervolgens ook opslaan in de trunk. Anders heeft het hoofdproduct dat nog steeds wordt doorontwikkeld nog dezelfde problemen. Als de branch-versie vervolgens ver genoeg is, besluit men een tag te maken. Dat is dan de eerste definitieve versie 1.0 van het product. Op een tag wordt niet doorontwikkeld. Dit is een vastgelegde versie en als je die versie ophaalt, weet je zeker dat alles wat daarin zit, ook werkelijk in versie 1.0 van het product zit verwerkt. Als er verder in het ontwikkelproces weer een zogenaamde bugfix-release moet komen, om fouten in de eerste versie op te lossen, kan men de code weer committen op de branch en trunk. Vervolgens maakt men nog een tag van deze branch.

Weerbarstige praktijk
Verschillende keren heb ik een kijkje genomen in ontwikkelomgevingen van andere bedrijven. De beproefde principes als hierboven beschreven, worden vaak niet zo gehanteerd. Vaak zag ik dat er versies uit de trunk gelijk in een productie-omgeving wordt gezet, zonder dat er iets wordt vastgelegd door bijvoorbeeld een tag te maken.

Ook trof ik situaties aan waar er gewerkt werd met CVS en deze versies bestonden:

|- Programma X - versie 1
|- Programma X - versie 1.5
\- Programma X - versie 2

Kortom, verschillende versies worden los opgeslagen of versie 1 was uitgecheckt. Vervolgens wordt er een versie 2 gemaakt en weer los ingecheckt. Deze manier van werken maakt het vergelijken van verschillende versies van een bestand erg lastig. Hier is niet doorontwikkeld op één code-base, maar elke versie wordt al losse entitieit gezien. Groot nadeel is dat als men in versie 2 zit, men aan de CVS-file geschiedenis niet kan zien wat de wijzigingen waren voordat er op versie 2 is gecommit.

Conclusie
Veel bedrijven gebruiken versiebeheersystemen, maar niet altijd op de goede manier. Dit artikel behandelde een paar concepten van CVS en SVN en daarmee hoopt het wat handreikingen te doen. Dit is vooral gebaseerd op common practice en staat altijd open voor feedback of verbeteringen. In een follow-up op dit artikel volgen meer details over de mogelijkheden met SVN en CVS.

Meer Info
Er zijn genoeg bronnen met zinvolle informatie over versiebeheersystemen. Deze pagina geeft interessante info over verschillende SVN clients.

Algemene SVN-documentatie is hier te vinden of als PDF-boek formaat.

Dit artikel bespreekt nog een aantal commentaren of praktijken van Subversion, ook wel interessant.