This article is in dutch, sorry...

Subversion heeft een standaard structuur voor elke repository die er zo uit ziet:

De root is een url, en die kan niet hoger worden opgevraagd, bijvoorbeeld: https://192.168.1.17:8443/svn/javaTraining

Onder de trunk worden de nieuwste sources ingecheckt. Als dat 1 project is kunnen de directories en files onder de root van het project hier meteen ingezet worden. Zijn het meerdere projecten, dan moeten de roots van de projecten hier ingezet worden. Dit is alleen zo gewenst als de projecten ook echt afhankelijk van elkaar zijn en niet worden gedeeld tussen verschillende projecten, dan moeten die in hun eigen repository worden opgeslagen.

Versienummering

Naast de build nummers worden er door mensen bedachte versie nummers gebruikt. De ideale situatie is dit. Er is een major en een minor nummer. Het minor nummer wordt bij elke (test) release met 1 verhoogd. Het major versienummer wordt verhoogd indien er een grote aanpassing van de code plaats vindt of wanneer er aan 2 versies tegelijk moet worden gewerkt. Dat is bijvoorbeeld bij het ingebruik nemen van de software door de klant met de benodigde bugfixes die soms nodig kunnen zijn en de ontwikkeling van een nieuwe versie. Als dat het geval is dan vind de ontwikkeling van de nieuwe versie plaats in de trunk en de bugfixes in de andere versie in de branch. Het maken van de branch kan uitgesteld worden tot dat er daadwerkelijk een bug optreed die opgelost moet worden in een huidige versie terwijl er ook wordt ontwikkeld aan een nieuwe versie.

De naam van de branch bevat alleen het major versie nummer. Als er een release plaats vindt, dan wordt die neergezet in de tags directory, inclusief het minor nummer.

Voorbeeld

Major versie nummer is: 1.1
Minor versie nummer is: 4
Complete huidige versie is 1.1.4
We vergeten even alle andere vorige versies, dit is de huidige situatie in de repository:

In de trunk wordt doorgewerkt aan de nieuwe versie, het is nog niet bepaald welke versie dat gaat worden. Maar ondertussen is 1.1.4 wel in productie bij een groot bedrijf en op een gegeven moment vinden ze een bug. Het is makkelijk te verhelpen. De ontwikkelaar die checkt versie 1.1.4 uit van svn en repareert de bug. Tags zijn read-only, dus de fix kan hij niet zomaar inchecken. Hij kopieerd 1.1.4 naar de branches folder in svn en noemt de branch 1.1. En commit zijn code in die branch. Nu ziet het er zo uit:

Versie 1.1.5 kan gereleased worden naar de klant en iedereen is blij. Als er nu een 2^de bug wordt gevonden wordt er een 1.1.6 versie gemaakt van de branch enzovoort. Deze bugs moeten ook worden opgelost in de versie in de trunk! Anders heeft een volgende nieuwe versie ineens weer oude bugs. Dit kan vaak makkelijk gedaan worden met behulp van de merge functie of patch functie van svn/Eclipse .

Twee maanden later is de nieuwe versie af waaraan wordt gewerkt in de trunk. En een eerste versie wordt opgeleverd voor de test. Deze versie kan niet major versie 1.1 krijgen omdat er dan gaan oplopende volgorde van features meer aanwezig is. Dus wordt het versie 1.2 of als er hele grote veranderingen zijn 2.0. Laten we het houden op 1.2. De eerste test versie wordt dan 1.2.0, er wordt nog geen branch gemaakt, omdat de trunk nu als branch fungeert:

Nu bestaan versie 1.2.x en 1.1.x naast elkaar en kunnen afzonderlijk gereleased worden.