soemirno

Ik was zeer tevreden met Subversion, totdat we op ons project in alle wijsheid besloten om tegelijk aan twee releases te werken. Als Agile aanhanger ben ik daar niet zo blij mee, je begint pas aan de volgende release als de huidige opgeleverd is, dat houdt het simpel. Het wees me echter wel op de beperkingen van Subversion.

Om parallel te kunnen werken hebben we een branch gemaakt in Subversion en hiervoor ook een automated build gemaakt in Teamcity. Ik wilde echter ook alle wijzigingen van main line aan het eind van de dag laten mergen met de branch. De volgende release zal immers ook alles van de huidige release moeten hebben en aangezien er heel veel afhankelijkheden waren, wilde je dat de extra branch zoveel mogelijk up to date was.

Maar mergen in subversion is niet triviaal. Je moet zelf bijhouden vanaf welke revisie is gemerged en je krijgt alle wijzigingen in een keer met een algemene commit message. Je verliest dus de informatie over de individuele commits.

[graphviz name=Graph01] node [ fontname = "Bitstream Vera Sans" fontsize = 10 ]; A -> B -> C-> D -> merged_with_trunk A-> E -> F -> G -> merged_with_trunk merged_with_trunk ->H G -> J H -> merged_trunk J-> merged_trunk [/graphviz]
In bovenstaand voorbeeld missen we dan de commit messages van E, F, G en J in de trunk en je moet ook zelf administreren dat je bij G al een merge hebt gedaan.

Een tweede manko van Subversion in ons proces was, dat we eisten dat een commit de build niet breekt. Bij elke commit start het build proces en als testen falen moeten deze meteen gefixed worden.

In wezen is dit prima, maar er was een complex stukje code met performance problemen, waar we een beetje met trial en error naar de beste oplossing aan het zoeken waren. Er werd in dit proces heel wat code geschreven en weer weggegooid zonder te committen en hierdoor krijg je aan het eind een grote commit met een algemene commit message.

Een gerelateerde beperking is het ontbreken van offline commits. Als je offline bent kun je niet committen en dan krijg je ook weer grote commits met veel wijzigingen en een algemene commit message. Niet handig als je weleens wat in de trein doet.

Kleine atomaire commits met een duidelijke commit message vind ik essentieel voor het kunnen onderhouden van de code. Als de tool dit niet in alle situaties mogelijk maakt, moeten we maar eens verder shoppen. De keuze is in wezen al gemaakt door de Ruby on Rails community: Git.