Results 1 to 4 of 4

Thread: Kan geschetste situatie met versiebeheer worden aangepakt of beter van niet ?

  1. #1

    Question Kan geschetste situatie met versiebeheer worden aangepakt of beter van niet ?

    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,
    Iedereen wist dat het onmogelijk was. Behalve dan die ene dwaas die dat niet helemaal goed had begrepen en het toch deed.

  2. #2
    De history in Git is een tree van commits.
    Elke commit heeft een parent (behalve de eerste).
    Meerdere commits kunnen de zelfde parent hebben. In dat geval heb je een vertakking.

    Git stelt je in staat om een labeltje aan een commit te hangen.

    Een tag is zo'n labeltje, en blijft in principe altijd op dezelfde plaatst staan. Tags worden vaak gebruikt voor het aanduiden van versienummers.

    Een branch is ook zo'n labeltje. Branches worden gebruikt om een leesbare naam aan een vertakking te hangen. Als je extra commits toevoegt aan een branch, schuift het branch label mee op, zodat het label altijd aan het einde (de head) van de vertakking blijft staan. Branches worden doorgaans gebruikt voor features die nog in ontwikkeling zijn, maar ook wel om meerdere versies naast elkaar door te ontwikkelen.

    Je kan in principe commits kopiëren van de ene branch naar de andere. Zo kan je een bugfix uit een nieuwe versie ook toepassen op een oude versie, zonder dat je ook direct alle features ervan overneemt.
    Je kan een branch 'Versie3' maken, waarin je versie 3 nog doorontwikkelt door er commits aan toe te voegen, terwijl je ook al in een Versie4 branch bezig bent. Elke release van versie 3 kan dan alsnog een tag (Versie 3.6) krijgen binnen die branch.

    Maar dat is wel handwerk. Git heeft voor zover ik weet geen manier om zomaar even een bestandje toe te voegen aan elke bestaande branch of tag.
    Er is wel een manier om commits te kopiëren (cherry picking). Het kan wel zijn dat die commit niet helemaal compatible is met die branch, en dat je dus conflicten moet oplossen.

    Git heeft een uitgebreide CLI die heel geschikt is om tegenaan te scripten, mede omdat de output van diverse commando's heel vast staat (of zelfs speciaal toe te spitsen is voor aanroepen binnen scripts), en de return codes goed aangeven of een commando is gelukt. Voor zover ik weet zijn zo'n beetje alle grafische Git clients alleen maar wrappers rondom de CLI. Je zou dus wellicht wel een script kunnen schrijven om een commit of bereik van commits te kopiëren naar een aantal andere branches, al zou ik hopen dat je ook weer niet zoveel versies hebt dat het echt rendabel is om dat niet met de hand te doen.

    Wat betreft de test-suites. Ik weet niet wat dat precies voor systeem is, maar ik hou normaal gesproken de test-code bij het project. Als ik een feature bouw, dan bouw ik ook de tests erbij. Dat betekent dus ook dat als ik een eerder commit terughaal (o.b.v. een tag, bijvoorbeeld, al gebruik ik die zelf weinig), dan krijg ik dus ook de tests die bij die versie horen. Dat lijkt me makkelijker dan een aparte repository. Als je dan een bug ontdekt waarvan je het gevoel hebt dat die ook op andere versies van toepassing is, dan kan je de commit(s) met de fix daarvoor én de aanvullende tests ervoor allemaal overnemen in de oude versies waarvoor je dat nog wilt.
    1+1=b

  3. #3
    Dank voor de snelle reactie GolezTrol.

    Ik heb helaas iets meer tijd nodig om enkele zaken die u vermeld dieper in te laten werken op mijn hersenpan.

    Ik reageer dan ook in eerste instantie maar even op die zaken die ik wel meteen kan uitleggen/begrijpen.

    Maar dat is wel handwerk. Git heeft voor zover ik weet geen manier om zomaar even een bestandje toe te voegen aan elke bestaande branch of tag.
    Ja daar kwam ik dus ook achter. Iets van 8-10 handelingen per tag, verdeelt over minimaal 10 tags.....

    Het is mij in dat opzicht duidelijk dat versiebeheer niets te zoeken heeft in een project zoals deze...

    Ik had van origine de indruk dat versie beheer nu juist gemaakt is om dit soort situaties op een makkelijkere manier (in vergelijking met handmatig) op te kunnen lossen maar ben er zelf ook nooit eerder met zo'n situatie zoals deze geconfronteerd.

    Wat betreft de test-suites. Ik weet niet wat dat precies voor systeem is, maar ik hou normaal gesproken de test-code bij het project.
    Dat doe ik normaliter dus ook. Echter is dit een nogal een "speciaal" projectje.

    Als ik een feature bouw, dan bouw ik ook de tests erbij. Dat betekent dus ook dat als ik een eerder commit terughaal (o.b.v. een tag, bijvoorbeeld, al gebruik ik die zelf weinig), dan krijg ik dus ook de tests die bij die versie horen. Dat lijkt me makkelijker dan een aparte repository.
    Helemaal mee eens en doe ik ook voor normale projecten.

    Echter, het project zelf moest zo snel mogelijk 'op' worden gebracht, waar ik op het moment aan heb voldaan.

    De test-suite is echter van dusdanig slechte kwaliteit dat er meer tijd nodig is om deze werkende te krijgen voor de verschillende versies van het project.

    Ik moet dus 'backwards' (en tegelijkertijd ook forwards) gaan werken en de suite aanpassen op de verschillende aanwezige versies.

    Ik zou er natuurlijk voor kunnen kiezen om dit eerst helemaal uit te werken om dan vervolgens de hele zwik aan een repository toe te voegen en dan pas te beginnen met tagging maar daar is de tijd helaas niet voor aanwezig.

    Als je dan een bug ontdekt waarvan je het gevoel hebt dat die ook op andere versies van toepassing is, dan kan je de commit(s) met de fix daarvoor én de aanvullende tests ervoor allemaal overnemen in de oude versies waarvoor je dat nog wilt.
    Precies dat. De werk-flow is en blijft "akelig" met versie-beheer, in ieder geval met git (geen idee of andere versie beheer software dat beter kan). En de situatie die je schetst zal in de toekomst zeker weten gaan gebeuren.

    Je hebt in ieder geval een goed punt om enkele zaken mbt git te kunnen automatiseren, daar had ik eerlijk gezegd nog niet zo over nagedacht.

    Ter verduidelijking,

    Ik spreek weliswaar over versie nummers en bugs maar in de praktijk gaat het erom dat het software project nuances aanbrengt op al bestaande thema's (dus niet echt verschillende versies) en de 'bugs' zijn meer te vergelijken met aanpassingen/verbeteringen die het project in de loop van de tijd aanbrengt (nieuwe inzichten enzow) waar 'vorige' versies die kennis nog niet hadden en zonder de nieuw aangebrachte oplossing om het daadwerkelijke probleem heen moesten werken. In het geval dat er tijdens het aanbrengen van een nieuwe nuance in een nieuwe versie van het project een verkeerde analyse (of fout in de analyse) is gemaakt moet deze ook kunnen worden geconstateerd in de oudere versies van de test-suite.

    Het uiteindelijke doel van de test-suite is om "fouten" (omheen werkingen) van de verschillende versies (nuances) van het project in kaart te brengen op een dusdanige manier dat de output hiervan geanalyseerd kan worden door weer een ander stukje software.

    Hierdoor kan de progressie van de verschillende nuances van het project in kaart worden gebracht, wat het uiteindelijke doel is. Deze data kan dan weer worden gebruikt om te zien of een bepaalde nuance juist de goede of de verkeerde kant uitgaat (iets wat momenteel niet mogelijk is en ervoor zorgt dat het project in zijn geheel in de onderste lade van de kast is beland).

    Of in het super kort: heel erg oude meuk een nieuw jasje geven, opfrissen en ervoor zorgen dat die meuk fris genoeg blijft.
    Iedereen wist dat het onmogelijk was. Behalve dan die ene dwaas die dat niet helemaal goed had begrepen en het toch deed.

  4. #4
    Ik heb er uiteindelijk voor gekozen om het op te lossen door voor de test-suite verschillende directories per versie aan te maken.

    Een bestand met de hand kopiëren/toevoegen naar/aan verschillende folders is simpelweg vele malen sneller dan hoe het volgens git zou moeten als je tags gebruikt.

    Als het geheel wat verder is uitgekristalliseerd zal ik daadwerkelijk tags gaan toevoegen en een werk-flow klaar hebben liggen voor toekomstige veranderingen/uitbreidingen.

    Dank voor de hulp GolezTrol
    Iedereen wist dat het onmogelijk was. Behalve dan die ene dwaas die dat niet helemaal goed had begrepen en het toch deed.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •