[ALG] Versiebeheer / Repository Layout

[Casteloni]

Ik heb nu al een tijdje ervaring met Subversion als versiebeheersysteem en ben er hardstikke tevreden mee. Nu ben ik het ook gaan inzetten voor de wat grotere projecten en maak ook gebruik van de branche / merge mogelijkheden.

Voor een J2EE project heb ik een aantal subprojecten, denk hierbij aan een web applicatie, de EJB's en een util / tool library. Ik heb dit nu als volgt ingericht:

code:

Project1
|------- ProjectWEB
         |-----trunk
         |-----BrancheA
|--------ProjectEJB
         |----trunk
         |----BrancheA
|--------ProjectUtil
         |----trunk
         |----BrancheA

Maar stel nu dat ik voor ProjectWEB een nieuwe gave functionaliteit ga ontwikkelen, hiervoor zijn ook grote aanpassingen nodig in ProjectUtil. Maak ik een nieuwe brancheB aan voor ProjectWeb en ProjectUtil?

Een andere mogelijkheid is om de 'branching' nog een niveau hoger te tillen, elke branche heeft dan vervolgens een Web / Util / EJB. Verder is er nog een trunk die tevens ook een Web / Util en EJB heeft. Een nadeel van deze aanpak lijkt me dat je soms een subproject in je branche hebt zitten waar je eigenlijk niks aan verandert.

Hoe kijken jullie hier tegen aan?

[mindcrash]

Hmm, ik zou je SCM niet op die manier indelen maar op de volgende manier:

code:

Project
|------- trunk
         |-----web
         |-----ejb
         |-----util
|------- branche
         |-----web
         |-----ejb
         |-----util

Dus bij elke grote wijziging in een willekeurig onderdeel branche je het hele project. Prima onderhoudbaar en lekker overzichtelijk. Ik zou me niet zo druk maken om subprojecten die niet wijzigen, liever iets teveel diskruimte usage dan het hebben van zoveel branches dat het gewoon niet meer manageable is

[misfire]

Subversion kent een soort de-facto standaard voor repository indelingen, die wordt beschreven in het svn boek, en er als volgt uitziet:

code:

Project
|------- trunk
|------- branches
|------- tags

Het is ongebruikelijk om branches direct onder de root te plaatsen omdat het dan minder duidelijk is dat het een branch betreft.

De keuze voor de indeling in één of meerdere trunks/branches hangt er voornamelijk van af of je een afgescheiden collaboratie-effort hebt, dwz, werk je met verschillende teams aan verschillende delen. Zo nee, dan is het makkelijker om alles in één trunk/branch te gooien. In Subversion maakt het niet uit of je dingen "onnodig" branched omdat alleen de verwijzing naar een revisie gekopieerd wordt (geen totale nieuwe kopie) en het dus geen extra diskspace kost. Als je wel met verschillende teams werkt zijn aparte branches handiger, omdat de teams bijvoorbeeld verschillende branch/merge momenten kunnen hebben.