Ik heb een vraag met betrekking tot versie beheer (git in het bijzonder omdat ik daar de meeste affiniteit mee heb).
Er is mij een project in de schoot geworpen (uit de welbekende oertijd), laten we zeggen project A, dat al een paar releases kent en beheerd is op z'n 'Jan-boeren-fluitjes' (met alle respect voor alle Jannen, boeren en fluitjes).
Na wat noeste arbeid heb ik dit project voor zover mogelijk in een git-repository weten te proppen en daar op de juiste plekken/momenten een release tag aangehangen. Het her-produceren van een complete commit geschiedenis (anders dan de nieuw aangebrachte) was helaas ondoenlijk.
Laten we het overigens voor het gemak van mijn vraag maar houden bij 10 releases, genummerd 1 t/m 10 (in werkelijkheid gaat het om meerdere variaties van verschillende thema's die in de loop der tijd steeds verder worden genuanceerd).
Tot dusver dan ook success !
Nu hoort er bij dat project ook een test-suite, laten we zeggen test-suite B. De staat van B is ... om te huilen.
In deze suite ontbreken de tests voor project A versie-nummers 1 t/m 3 en is de gehele test-suite tijdens zijn leven vanaf dat moment meegegroeid met het versie-nummer van project A t/m de release van versie-nummer 7. Daarna ontbreekt elk spoor.
Maw er is van deze test-suite in het geheel weinig tot geen enkele geschiedenis terug te herleiden anders dan enkele commentaren die aanwezig zijn in de huidig bestaande bestanden.
Opdracht/doel is wel om deze geschiedenis te her-produceren door de test-suite beschikbaar te maken voor alle aanwezige (en toekomstige) versie-nummers van project A.
Ik zal dus in ieder geval aan de bak moeten om alle ontbrekende delen in/aan te vullen.
Bij het voorbereiden op het werk wat me te wachten staat kom ik al snel knel te zitten mbt hoe dat het beste aan te pakken.
Ik zat te denken om voor test-suite B een eigen repository aan te maken (onafhankelijk van de repository van Project A) en deze in eerste instantie te baseren op Project A versie nummer 7 (de huidige status van de test-suite) middels aparte folder (gebaseerd op versie nummer) in de test-suite repository en vanaf daar voor elk versie-nummer apart een nieuwe folder in de test-suite repository aan te maken.
Op die manier zou ik zowel vooruit als achteruit aan een specifiek versie-nummer voor de test-suite kunnen gaan werken (na gelang de behoefte). Daarbij biedt het de mogelijkheid om (iets wat in de praktijk vaak bij dit project voorkomt) bij een nieuwe release van project A een fout te constateren, die door de testsuite voor alle bestaande versies dient te worden (be/afge)handeld.
Echter, toen ik over deze oplossing wat langer ben gaan nadenken, bedacht ik mij dat het misschien ook mogelijk is om dit middels versie-beheer op te lossen (in plaats van folders met een versienummer), waarbij ik dan zat te denken aan het gebruik van tags.
Echter, als ik op het intersnert specifiek zoek naar/lees over: git, tags en toevoegen van een nieuw bestand aan alle bestaande tags en het aanpassen/toevoegen van bestanden aan reeds bestaande tags dan blijft het akelig stil.... en is het dus blijkbaar niet mogelijk hier een geschikte 'flow' voor te vinden. Wat eigenlijk ook wel weer logisch is omdat een tag (vzib) meer een moment-opname van je repository is.
Dus vraag ik mij af of het gebruik van tags uberhaupt wel loont voor een situatie zoals deze (alhoewel ik niets anders mbt git heb kunnen vinden wat van toepassing zou kunnen zijn op geschetste situatie).
Hoe zouden jullie zo'n situatie aan pakken ? Kan versiebeheer zoals git daar uberhaupt bij behulpzaam zijn ? En hoe zit dat nu eigenlijk met het gebruik van tags ?
Alle overige opmerkingen/suggesties zijn natuurlijk ook van harte welkom.
Lange koele briesjes,
Bookmarks