Versioning systeem voor verschillende modules,zelfde source

[Robbeke]

Beste tweakers,

Ik ben al een tijdje aan het googlen en via de search vind ik niet wat ik zoek, misschien gewoon omdat ik de juiste zoektermen niet gebruik. Ik heb ook wat documentatie doorgenomen van Git en in mindere mate subversion. Ik ben een complete nieuweling in versioning systemen en begrijp wel wat er staat, maar ik slaag er niet in om dit te vertalen in een opstelling zoals ik ze praktisch wil organiseren.

Zie hier mijn probleemstelling:

Ik ontwikkel in een cms pakket dat vrij frequent updates aanlevert. Voor dit pakket ontwikkel ik een aantal modules zoals plugins en themes om extra mogelijkheden toe te voegen.
Uiteraard probeer je te vermijden dat bestanden uit het originele pakket moeten worden aangepast in de modules, maar soms is het gewoon noodzakelijk omdat het beschikbare extension systeem niet toestaat om alles te realiseren.

Ik ben dus op zoek naar een systeem waarbij ik het "core" cms pakket heb als root entiteit, en verschillende afgeleide modules. In elke module kunnen dus aanpassingen gebeuren in dezelfde bestanden van het core framework.
Elke entiteit (zowel core met updates van leverancier, als elke van mijn eigen module) moet apart bijgewerkt kunnen worden, eventueel door meerdere personen.
Als eindresultaat wil ik het core framework met alle modules toegepast (en dus de noodzakelijke aanpassingen door modules toegepast) kunnen exporteren en synchroniseren met een productie en/of development omgeving.

Ik heb Git submodules bekeken, maar hiervan vond ik terug dat ze in aparte submappen moeten zitten. In mijn geval gaat het om een overlappende directory structuur (modules hebben bestanden in mappen van het core framework).

Kan iemand me zeggen of een systeem zoals dit mogelijk is, met welk versioning pakket en een algemeen overzicht geven hoe dit hierin gestructureerd moet worden?
Ik heb een lichte voorkeur voor Git, maar ik heb geen idee of het hiermee moet lukken.

[Keeper]

Wat voor versioning systeem gebruikt het CMS pakket waar het hier om gaat? Als zij ook git gebruiken, en een publieke repository hebben, kan je die gewoon clonen en op basis van die code je eigen wijzigingen in die core maken.

Als er dan een update van hun systeem komt kan je die gewoon in jouw clone mergen, waarbij je mogelijk enkele merge conflicts moet oplossen, maar dat hoeft niet.

Vervolgens kan je je eigen modules (los van de core) gewoon in een aparte repository of als submodules in het CMS opnemen.

[Robbeke]

Keeper schreef op dinsdag 03 januari 2012 @ 19:08:
Wat voor versioning systeem gebruikt het CMS pakket waar het hier om gaat? Als zij ook git gebruiken, en een publieke repository hebben, kan je die gewoon clonen en op basis van die code je eigen wijzigingen in die core maken.

Als er dan een update van hun systeem komt kan je die gewoon in jouw clone mergen, waarbij je mogelijk enkele merge conflicts moet oplossen, maar dat hoeft niet.

Er is een SVN repository beschikbaar

Keeper schreef op dinsdag 03 januari 2012 @ 19:08:
Vervolgens kan je je eigen modules (los van de core) gewoon in een aparte repository of als submodules in het CMS opnemen.

- Hoe kan ik deze aparte repositories dan mergen in het core systeem?
- Kunnen submodules dan in de bestaande directory structuur van het core systeem werken? Als ik de GIT documentatie lees krijg ik echt het idee dat een submodule een aparte map moet zijn

[pderaaij]

Bij mijn werkgever doen we dit ook met diverse pakketten zoals Joomla en TinyMCE. Wij maken gebruik van een techniek die Vendor Branching heet, dit wordt ook beschreven in het SVN boek: http://svnbook.red-bean.com/en/1.1/ch07s05.html

Werkt bij ons bijzonder prettig en is erg betrouwbaar.

[Robbeke]

pderaaij schreef op dinsdag 03 januari 2012 @ 20:00:
Bij mijn werkgever doen we dit ook met diverse pakketten zoals Joomla en TinyMCE. Wij maken gebruik van een techniek die Vendor Branching heet, dit wordt ook beschreven in het SVN boek: http://svnbook.red-bean.com/en/1.1/ch07s05.html

Werkt bij ons bijzonder prettig en is erg betrouwbaar.

Dit lijkt erg sterk op wat ik nodig heb.

- Als het pakket enkel via SVN wordt aangeboden, dan ben ik waarschijnlijk verplicht om te volgen? Of kan het alsnog met Git?
- hebben ze in Git een gelijkaardig systeem als vendor branching?

[Soultaker]

De constructie die Keeper beschrijft kan ook prima als de broncode niet in Git zit. Je maakt dan gewoon zelf een Git repository voor het upstream project aan, en updatet die steeds wanneer er een nieuwe versie wordt uitgebracht.

Vervolgens maak je voor elke door jou ontwikkelde module een branch van die code. Wanneer het upstream project geüpdatet is, kun je elke module ook updaten (met git rebase of git merge).

Het eindresultaat dat je wil kun je dan simpelweg als aparte branch zien, waarin je periodiek alle module branches merget. Dan moet je er natuurlijk wel voor zorgen dat die modules zo min mogelijk conflicten introduceren, anders wordt het mergen een hel. Maar dat geldt natuurlijk voor elk versioning systeem.

[SoulWar1]

Die methode lijkt mij onnodig complex en fout gevoelig. Kun je de core library niet forken en op de plaatsen waar je module specifieke code hebt staan een event triggeren? In de modules kun je dan een listener op die events laten reageren. De code van de core library zou niet afhankelijk mogen zijn van welke modules je wel of niet gebruikt.

[Robbeke]

Soultaker schreef op dinsdag 03 januari 2012 @ 20:51:
De constructie die Keeper beschrijft kan ook prima als de broncode niet in Git zit. Je maakt dan gewoon zelf een Git repository voor het upstream project aan, en updatet die steeds wanneer er een nieuwe versie wordt uitgebracht.

Vervolgens maak je voor elke door jou ontwikkelde module een branch van die code. Wanneer het upstream project geüpdatet is, kun je elke module ook updaten (met git rebase of git merge).

Het eindresultaat dat je wil kun je dan simpelweg als aparte branch zien, waarin je periodiek alle module branches merget. Dan moet je er natuurlijk wel voor zorgen dat die modules zo min mogelijk conflicten introduceren, anders wordt het mergen een hel. Maar dat geldt natuurlijk voor elk versioning systeem.

Dus als ik het goed begrijp:

- Git repository met het core framework. Manueel te updaten bij elke periodieke release.
- Een branch per module
- Een branch waarin alle modules gemerged worden met het core framework (bvb "branch_final").

Wanneer ik de core update, moet ik via rebase of merge de aanpassingen van merge toepassen op de branches. Kan dit voor elke branche apart zonder problemen?

Ik zou dus bij update van een module de branch_final moeten mergen met deze nieuwe versie. Vervolgens een patch maken (met diff?) voor de bestaande installaties die hierop gebaseerd zijn...

Klopt dit zo ongeveer?

[Robbeke]

SoulWar1 schreef op dinsdag 03 januari 2012 @ 21:13:
Die methode lijkt mij onnodig complex en fout gevoelig. Kun je de core library niet forken en op de plaatsen waar je module specifieke code hebt staan een event triggeren? In de modules kun je dan een listener op die events laten reageren. De code van de core library zou niet afhankelijk mogen zijn van welke modules je wel of niet gebruikt.

Soulwar, heb je het over het voorstel van Soultaker?
Ik argumentatie is wel niet duidelijk voor mij. Je zegt dat de Git oplossing niet zo goed zal werken, maar ik kan niet helemaal volgen met de redenen die je geeft.

[ Voor 13% gewijzigd door Robbeke op 03-01-2012 21:49 ]

[SoulWar1]

Ik heb het inderdaad over het voorstel van Soultaker. Tegenargumenten zijn:
- Veel onderhoud; iedere branch moet je bijwerken bij een update of hotfix.
- Meerdere productie branches (per combinatie of module er wel/niet inzit); en hoe wil je bijhouden welke modules je er wel of niet in gemerged hebt.
- Merge conflicten; wat gebeurd er als meerdere modules hetzelfde stukje in de core veranderen...of zelfs op een net iets andere manier.
- Moeilijk te testen, je weet niet of wijzigen in 1 module gevolgen hebben voor een andere module.

Het echte probleem zit hem hier in de verstrengeling tussen de core en de modules. Dus ik zou energie steken om deze 2 uit elkaar te halen met bijv een EventManager. Maar er zijn nog wel andere oplossingen hiervoor.

[Robbeke]

SoulWar1 schreef op dinsdag 03 januari 2012 @ 22:32:
Ik heb het inderdaad over het voorstel van Soultaker. Tegenargumenten zijn:
- Veel onderhoud; iedere branch moet je bijwerken bij een update of hotfix.
- Meerdere productie branches (per combinatie of module er wel/niet inzit); en hoe wil je bijhouden welke modules je er wel of niet in gemerged hebt.
- Merge conflicten; wat gebeurd er als meerdere modules hetzelfde stukje in de core veranderen...of zelfs op een net iets andere manier.
- Moeilijk te testen, je weet niet of wijzigen in 1 module gevolgen hebben voor een andere module.

Is je commentaar geldig voor elk versioning systeem of specifiek voor de Git oplossing? Heeft Subversion mogelijkheden om dit anders/beter op te lossen?

SoulWar1 schreef op dinsdag 03 januari 2012 @ 22:32:
Het echte probleem zit hem hier in de verstrengeling tussen de core en de modules. Dus ik zou energie steken om deze 2 uit elkaar te halen met bijv een EventManager. Maar er zijn nog wel andere oplossingen hiervoor.

Hier volg ik je niet helemaal... een EventManager in het versioning systeem of in het product zelf?

[B-Man]

Hij bedoelt dat je beter een stuk abstracte functionaliteit (zoals een EventManager) aan de core kan toevoegen, zodat je je modules daarop kunnen aanhaken.
Dit zorgt ervoor dat je niet per module de core hoeft aan te passen, maar dat je modules ervanuitgaan dat de core gepatched is met je EventManager klasse.

Denk aan zoiets:

code:

class EventManager {
    static EventManager getInstance();
    void listenFor(Event, Listener);
    void stopListening(Event, Listener);
    void triggerEvent(Event);
}

Je modules kunnen nu via listenFor() luisteren naar events, en andere modules (of eventueel meer patches voor core) triggeren die events.