In deze blog leggen we uit hoe we ons versiebeheer hebben georganiseerd om voor verschillende opdrachtgevers tegelijkertijd aan dezelfde open source code te kunnen ontwikkelen. Een belangrijk doel van onze werkwijze is om die aanpassingen eenvoudig uit te wisselen tussen de verschillende opdrachtgevers. Bovendien kunnen opdrachtgevers en anderen precies zien welke features voor eigen gebruik interessant zijn.
Workingsets
Voor het versiebeheer van onze open source software gebruiken we Subversion, gehost op Sourceforge. Een typische Subversion repository is opgedeeld in tags voor versies, een trunk waarop de wijzigingen worden gemaakt voor een release en eventueel branches voor de ontwikkeling van specifieke aanpassingen. In onze benadering vervalt de trunk en organiseren we branches in workingsets. De tags directory bevat zoals gebruikelijk de versies die gepubliceerd worden. Zodra we een nieuwe feature ontwikkelen, maken we eerst een workingset op basis van een specifieke tag.
De directory tree van een project ziet er dan als volgt uit:
meresco-solr/
tags/
version_0.9/
...
version_1.0/
...
version_1.1/
...
workingsets/
1.1-projectX/
...
1.0-projectY/
...
Een workingset bevat op zichzelf weer interne versies en branches. Binnen een nieuwe workingset beginnen we met version_0, dus:
$ svn cp tags/version_1.1 workingsets/1.1-projectX/version_0
De ontwikkeling van feature A gebeurt in version_0-feature_A:
$ cd workingsets/1.1-projectX $ svn cp version_0 version_0-feature_A
De tree voor deze workingset ziet er nu als volgt uit:
workingsets/
...
1.1-projectX/
version_0/
...
version_0-feature_A/
...
Als feature_A klaar is, bundelen we de wijzigingen in een changeset voor die feature door de diff te nemen tussen version_0 en version_0-feature_A. Die changeset plaatsen we in een subdirectory applied en we maken version_1:
workingsets/
...
1.1-projectX/
version_0/
...
version_1/
applied/
...
201103081154.feature_A.changeset
...
Conclusie
Door op deze manier te werken met workingsets kunnen we in dezelfde periode voor verschillende projecten ontwikkelen aan dezelfde source code zonder dat dit conflicten oplevert. Daarbij worden alle veranderingen voor een story expliciet in één changeset gecombineerd. Zolang workingsets naast elkaar bestaan kunnen individuele changesets desgewenst van elkaar worden overgenomen. Dit werkt veel eenvoudiger dan het mergen zoals we dat gewend waren voor de introductie van de changesets.
Op een bepaald moment kunnen we besluiten dat een workingset klaar is om als officiële versie gepubliceerd te worden. Binnen de applied directory van de tag blijven alle changesets beschikbaar. Het mooie hiervan is dat we een changeset ook op oudere versies kunnen toepassen, bijvoorbeeld om een specifiek productieprobleem snel op te lossen zonder eerst een volledige upgrade te hoeven doen.
Voor onze open source projecten is deze manier van werken live te volgen op, bijvoorbeeld: http://meresco.svn.sourceforge.net/viewvc/meresco/meresco-core/.
De changesets publiceren we op: http://meresco.org/page/changesets.