Source code control voor privéwijzigingen van een pakket

[Anoniem: 116604]

Een waarschijnlijk tamelijk dommige vraag... Maar ik voel me een beetje overdonderd door de grote hoeveelheden Unicode in de manuals van de pakketten die ik heb doorgebladerd (en wat er op dit forum in het verleden over dit onderwerp is geschreven), dus vraag ik het voor alle zekerheid maar even na.

Probleem: voor mijn eigen blogje op basis van Wordpress en thema Atahualpa verbouw ik met nogal groot plezier allerhande dingen in de broncode van de laatste. Wat dus tot voorspelbaar gevolg heeft dat als ontwikkelteam BytesForAll een nieuwe versie van Atahualpa uitbrengt die ik óók wil gebruiken, ik al mijn eigen wijzigingen zal moeten doorvoeren. Tot nu toe deed ik dat met de hand, hetgeen een nogal vervelend klusje is. Ergo, ik wilde tegelijk met een aantal andere dingen overstappen op een net RCS om mijn privéwijzigingen in bij te houden, en, heel belangrijk, dat het doorvoeren van deze wijzigingen in een nieuwe versie van Atahualpa zoveel mogelijk automatisch gaat. Punt is echter wel: ik volg de wijzigingen in de code van Atahualpa niet op de voet, maar haal ze, zeg, eens per half jaar als een soort 'major release' op (ook al is de dan courante versie niet echt een 'major release').

Nu is mijn laatste ervaring met een RCS het stokoude 'echte' RCS (en dat ook nog dik 15 jaar geleden), en het gebied heeft niet stilgezeten. Bijkans is mijn magere kennis over het onderwerp ontoereikend. Ik heb het donkergrijze vermoeden dat wat ik wil eigenlijk totaal geen probleem is voor een beetje capabel RCS, maar toch maak ik me zorgen over wat ik wil wel kan. Ik heb niet zoveel zin om een paar weken te ploeteren met een pakket om dan tot de conclusie te komen dat ik iets anders nodig heb—zo ruim zit ik nu ook weer niet in mijn vrije tijd.

Dus als een vriendelijke ziel mij kort zou kunnen uitleggen hoe ik het bovenstaande in een RCS moet organiseren (en welk RCS dat is—CVS, Git, Mercurial, Subversion, ...—maakt me op dit moment niet zoveel uit tenzij de ene het wel kan en de ander niet natuurlijk), dan hoor ik dat erg graag. Het daadwerkelijke opzetten van het RCS zal me wel lukken, dus dat hoef je niet uit te leggen .

[Niemand_Anders]

Welk VCS je gebruikt maakt op zich niet zoveel uit. Aangezien je in het verleden hebt gewerkt met RCS zijn CVS en SVN logische kandidaten.

Het probleem is eigenlijk dat je twee gescheiden development trajecten hebt (je eigen wijzigingen en die originele broncode) welke lastig in sync zijn te houden.

De eerste stap is om voor de laatste keer even handmatig jouw wijzigingen op de originele code door te voeren en deze versie dan in VCS te plaatsen (import).

Het is echter wel belangrijk dat je regelmatig een nieuwe versie van de originele binnenhaalt en die over de custom code legt. Als je dit regelmatig doet, heb je de minste kans op conflicten. En als je toch een conflict krijgt is deze meestal eenvoudig te verhelpen.

Als de wijzingen ten opzicht van de originele code vrij klein zijn en je vooral nieuwe bestanden toevoegt (zoals je eigen thema), kun je volstaan door van tijd tot tijd een label op de code te plaatsen.

Als jouw code steeds meer gaat afwijken van de originele code, dan zul je waarschijnlijk moeten gaan werken met branches. Naar mate je meer van de originele code hebt aangepast, des te lastiger het zal zijn om jouw code in sync te houden met de originele wordpress code.

Een andere techniek is ook mogelijk. Je kunt bij elke release van wordpress een diff uit de SVN repository trekken en die diff als een patch loslaten op je code. Echter zul je de diff wel moeten nalopen om te zorgen dat de diff niet jouw wijzigingen (gedeeltelijk) ongedaan maakt.

Maar misschien de beste optie is misschien nog wel om de wijzigingen (op wordpress) niet prive te houden, maar een developer account aanmaken bij wordpress en je wijzigingen delen. Als het goede wijzigingen zijn zal iedereen daarvan profiteren en zullen de wijzigingen sneller worden geaccepteerd. Sommige projecten vragen aan nieuwe developers eerst om een aantal keren een diff te posten in de issue tracker voordat je schrijf rechten krijgt op de repository. Git en Mercurial zijn een stuk sterker op dit gebied omdat deze een beter pull/push model hebben. Vooral github maakt pull requests wel heeel erg eenvoudig.

Maar de werking van git/mercurial is door de distributed repository wel erg anders van bij centrale repositories zoals CVS, SVN en TFS.

[Herko_ter_Horst]

Eens met bovenstaande, behalve dat CVS echt niet meer van deze tijd is (wordt ook niet meer aan doorontwikkeld). SVN is in alle opzichten beter dan CVS.

[TweakPino]

Voor wordpress themes is er een svn pagina beschikbaar: http://themes.svn.wordpress.org/atahualpa/, daarom zou ik als eerste naar svn kijken. Zelf heb ik alleen maar ervaring met git, daarmee moet het ook wel lukken

[Not Pingu]

Wat jij nodig hebt is niet zozeer een versiebeheersysteem maar een diff-en-compare tool zoals WinMerge of BeyondCompare.

[YopY]

Ik ben zelf voorstander van Git; wat ik zou doen is:

* Hun versies in 'master' hangen; als ze versiebeheer waar je bij kunt hebben des te beter.
* Bij elke update dat committen of pullen in je lokale master
* Je eigen branch bijhouden met wijzigingen
* Bij elke update of om de zoveel tijd een merge doen van master naar je 'prive'-branch

Git zal dan de meeste conflicten op kunnen lossen dmv merges en dergelijke. Als je regelmatig dezelfde merge conflicten krijgt die je op dezelfde manier oplost kun je de 'git rerere' instelling aanzetten, die neemt je conflict resolution op.

[/niet-n00b-vriendelijk-geformuleerde post]

[STW]

YopY schreef op donderdag 22 november 2012 @ 12:10:
Ik ben zelf voorstander van Git; wat ik zou doen is:

* Hun versies in 'master' hangen; als ze versiebeheer waar je bij kunt hebben des te beter.
* Bij elke update dat committen of pullen in je lokale master
* Je eigen branch bijhouden met wijzigingen
* Bij elke update of om de zoveel tijd een merge doen van master naar je 'prive'-branch

Git zal dan de meeste conflicten op kunnen lossen dmv merges en dergelijke. Als je regelmatig dezelfde merge conflicten krijgt die je op dezelfde manier oplost kun je de 'git rerere' instelling aanzetten, die neemt je conflict resolution op.

[/niet-n00b-vriendelijk-geformuleerde post]

Ik zou Git ook boven SVN verkiezen. Git kan zonder al te veel problemen een SVN repository benaderen en uitlezen. Maar het grote voordeel van Git is dat de 'intelligentie' bij het mergen vele malen beter is dan bij SVN. Het resultaat is veel minder conflicts. Voor het oplossen van de resulterende conflicts kan je goed een van de eerder genoemde tools gebruiken.

[Hydra]

Not Pingu schreef op woensdag 21 november 2012 @ 22:03:
Wat jij nodig hebt is niet zozeer een versiebeheersysteem maar een diff-en-compare tool zoals WinMerge of BeyondCompare.

Het enige juiste antwoord m.i. SourceControl gaat je probleem van het mergen van wijzigingen niet oplossen. Daar heb je een goeie mergetool voor nodig.

[Sardaukar]

Hydra schreef op donderdag 22 november 2012 @ 14:33:
[...]
Het enige juiste antwoord m.i. SourceControl gaat je probleem van het mergen van wijzigingen niet oplossen. Daar heb je een goeie mergetool voor nodig.

Klinkklare onzin.

Een diff/merge tool zal slechts tussen 2 states (originele software en zijn modificaties) de wijzigingen als 1 diff kunnen weergeven.

Hij wil echter meerdere wijzigingen kunnen maken en deze later ook weer kunnen toepassen als er een nieuwe versie van de originele software komt. Dit roept gewoon om een behoorlijk versiebeheer systeem.

Ik zou het toepassen door in Git de originele software in 'master' te zetten. De wijzigingen zet je dan in een aparte branch. Je kunt er dan voor kiezen om nieuwe wijzigingen toe te voegen en jouw branch vervolgens te rebasen ten opzichte van master. Hiermee heb je ook alle wijzigingen van master binnen.

Let wel: het zal alsnog een flinke klus worden als zijn wijzigingen flink uit elkaar gaan lopen ten opzichte van de originele code.

Hoe vaker je bovenstaand proces doorvoert (onder het motto: 'merge early, merge often'), des te minder conflicten zou je moeten hebben.

[Hydra]

Sardaukar schreef op vrijdag 23 november 2012 @ 15:21:
Klinkklare onzin.

Zeg ik dat hij geen sourcecontrol moet gebruiken dan?

[Sardaukar]

Hydra schreef op vrijdag 23 november 2012 @ 15:39:
[...]
Zeg ik dat hij geen sourcecontrol moet gebruiken dan?

Je zegt letterlijk dat source control zijn problemen van het mergen niet gaat oplossen.

Met alleen een merge tool ga je zijn probleem niet oplossen.

[Hydra]

Zijn probleem is dat hij een stuk open source uitbreidt, in de code, en dat er regelmatig van die open source software nieuwe update krijgen waar hij zijn wijzigingen in moet mergen. "Merge early merge often" lukt in dit geval gewoon niet omdat hij alleen merged op het moment dat er een nieuwe versie van de software geleverd wordt.

M.i. is dit vervelend en tijdrovend werk waarin je vooral veel hebt aan een goeie mergetool die het mergen van 2 sourcefiles met overlap makkelijker maakt. Zoals de TS aangeeft verbouwt hij dingen in de source van de applicaties waarvan dan geregeld nieuwe versies komen, waarin hij weer die source wijzigingen door moet voeren. Ik zie niet hoe het stellen dat een goeie mergetool daar onontbeerlijk is "klinkklare onzin" is. Of anders, leg jij eens uit hoe jij het mergen van sources zonder mergetool zou doen? Nergens zeg ik dat hij geen sourcecontrol moet gebruiken, ik zeg alleen dat de ingebouwde mergetools daarin niet goed genoeg zijn voor dit specifieke probleem.

[ Voor 8% gewijzigd door Hydra op 23-11-2012 15:59 ]

[Sardaukar]

Hydra schreef op vrijdag 23 november 2012 @ 15:59:
Zijn probleem is dat hij een stuk open source uitbreidt, in de code, en dat er regelmatig van die open source software nieuwe update krijgen waar hij zijn wijzigingen in moet mergen. "Merge early merge often" lukt in dit geval gewoon niet omdat hij alleen merged op het moment dat er een nieuwe versie van de software geleverd wordt.

M.i. is dit vervelend en tijdrovend werk waarin je vooral veel hebt aan een goeie mergetool die het mergen van 2 sourcefiles met overlap makkelijker maakt.

Het is juist het achterliggende versiebeheer systeem wat een merge makkelijker kan maken door de manier waarop de informatie van de diffs worden opgeslagen. Git kent bijvoorbeeld niet eens een ingebouwde diff/merge tool: dat configureer je. De merge tool is stukken minder belangrijk dan het onderliggende versiebeheer systeem.

Met alleen een mergetool (KDiff / Winmerge) kun je zijn scenario niet uitvoeren. Dat is het punt wat ik probeerde te maken. Ik zou zelfs zonder merge tool met Git zijn scenario wel uit kunnen voeren. (Toegegeven, stukken makkelijker met een merge tool, maar ik zou het wel kunnen).

Mijn geschetste scenario blijft overeind staan. Je hebt wel gelijk dat hij het zich makkelijker kan maken door vaker zijn wijzingen te rebasen/mergen. Het zou dus lonen door regelmatig nieuwe wijzigingen van de originele source binnen te trekken.

[Hydra]

Sardaukar schreef op vrijdag 23 november 2012 @ 16:13:
Het is juist het achterliggende versiebeheer systeem wat een merge makkelijker kan maken door de manier waarop de informatie van de diffs worden opgeslagen. Git kent bijvoorbeeld niet eens een ingebouwde diff/merge tool: dat configureer je. De merge tool is stukken minder belangrijk dan het onderliggende versiebeheer systeem.

Niet mee eens, sorry. Hij moet wijzigingen die hij in de source aanbrengt iedere keer dat er een nieuwe versie uitkomt gaan mergen naar de source files in de nieuwe release. Natuurlijk is een goed versiebeheertool onontbeerlijk (zelfs al werk je helemaal alleen aan code) maar hij moet bij wijze van iedere keer de diff tussen "custom index.php" en "versie n-1 index.php" migreren naar "versie n index.php".

Dit is gewoon een heel ander scenario dan een gewoon project waar je met meerdere mensen aan een project werkt. In zijn geval is het meer een kwestie van 2 mensen die werken aan een project en persoon 2 gooit gewoon doodleuk iedere 'commit' jouw wijzigingen weg. Een goeie mergetool heb je dan nodig om 1) te identificeren wat je precies t.o.v. de standaard gewijzigd hebt en 2) dit te patchen in de nieuwe versie.

Neemt overigens niet weg dat de aanpak van de TS mij enorm vervelend werkt. Mij lijkt het beter om al je wijzigingen sowieso in modules te houden en de source van het origineel zoveel mogelijk met rust te laten.

[Sardaukar]

Hydra schreef op vrijdag 23 november 2012 @ 16:32:
[...]
Niet mee eens, sorry. Hij moet wijzigingen die hij in de source aanbrengt iedere keer dat er een nieuwe versie uitkomt gaan mergen naar de source files in de nieuwe release. Natuurlijk is een goed versiebeheertool onontbeerlijk (zelfs al werk je helemaal alleen aan code) maar hij moet bij wijze van iedere keer de diff tussen "custom index.php" en "versie n-1 index.php" migreren naar "versie n index.php".

Je blijft echter consequent een ding over het hoofd zien: zijn eigen wijzigingen.

Als hij meerdere wijzigingen maakt en deze elk met een versiebeheer systeem verwerkt zijn deze makkelijker te mergen dan jouw situatie waarin je domweg een merge tool de state tussen twee source code bases laat verwerken.

Waarom? Omdat bij de situatie met het versiebeheer systeem er meer informatie voor handen is (zijn reeks van commits + de commits die op de originele codebase worden toegevoegd) om een merge makkelijker te maken.

In dat opzicht is een versiebeheer systeem een must en altijd beter dan de situatie die jij schetst.

[ Voor 0% gewijzigd door Sardaukar op 23-11-2012 17:48 . Reden: Schreeuwende tekst weggehaald ]

[Hydra]

Schets ik dan een situatie zonder versiebeheersysteem? Nee.

[Sardaukar]

Kom nou, je zegt letterlijk:

"
SourceControl gaat je probleem van het mergen van wijzigingen niet oplossen. Daar heb je een goeie mergetool voor nodig."

"

Daarmee impliceer je dat een VCS het probleem niet voor je oplost. Als ik je zin herformuleer: 'het lost het mergen van wijzigingen niet voor je op'. Ergo: je hebt een VCS niet nodig.

Vervolgens schets ik een scenario waarin ik toelicht dat een VCS je juist meer handvatten geeft om merges makkelijker te maken en daarna kom je met de opmerking dat je niet hebt gezegd dat hij het zonder VCS moet doen.

Wat wil je nu precies? Ik hoor in ieder geval geen oplossing van je voor de OP.

OP: Succes ermee! Ik blijf bij mijn standpunt dat je eens naar Git zou kunnen kijken met een rebase branch scenario. Ik heb hier zelf in het verleden ook met succes mee gewerkt in vergelijkbare omstandigheden.

Mail/DM me anders maar als je wat meer informatie zou willen hebben.

[ Voor 3% gewijzigd door Sardaukar op 23-11-2012 19:17 ]

[H!GHGuY]

Er wordt nog een scenario over het hoofd gezien:
Maak je patches generiek genoeg en geef ze terug aan het project.

Voordelen:
- je code wordt door anderen onderhouden
- je code is voor anderen beschikbaar
- je code kan door anderen verbeterd worden

Maak de dingen die echt niet generiek genoeg zijn om terug te geven aan het originele project zo klein mogelijk door zoveel mogelijk dingen die wel generiek zijn terug te geven of door ze configureerbaar te maken.

[Waster]

Sardaukar schreef op vrijdag 23 november 2012 @ 18:57:
Kom nou, je zegt letterlijk:

"
SourceControl gaat je probleem van het mergen van wijzigingen niet oplossen. Daar heb je een goeie mergetool voor nodig."

"

Daarmee impliceer je dat een VCS het probleem niet voor je oplost. Als ik je zin herformuleer: 'het lost het mergen van wijzigingen niet voor je op'. Ergo: je hebt een VCS niet nodig.

Vervolgens schets ik een scenario waarin ik toelicht dat een VCS je juist meer handvatten geeft om merges makkelijker te maken en daarna kom je met de opmerking dat je niet hebt gezegd dat hij het zonder VCS moet doen.

Wat wil je nu precies? Ik hoor in ieder geval geen oplossing van je voor de OP.

OP: Succes ermee! Ik blijf bij mijn standpunt dat je eens naar Git zou kunnen kijken met een rebase branch scenario. Ik heb hier zelf in het verleden ook met succes mee gewerkt in vergelijkbare omstandigheden.

Mail/DM me anders maar als je wat meer informatie zou willen hebben.

Wikipedia: Denying the antecedent

Hydra zegt een VCS lost je probleem niet op. Dit impliceert niet dat geen VCS wel je problemen oplost.

[Sardaukar]

Never mind.

[ Voor 109% gewijzigd door Sardaukar op 23-11-2012 21:25 ]

[Hydra]

Waster schreef op vrijdag 23 november 2012 @ 20:50:
Hydra zegt een VCS lost je probleem niet op. Dit impliceert niet dat geen VCS wel je problemen oplost.

Precies. Ik snap ook niet dat je dat er in kunt zien. Maargoed, dan is duidelijk waar die verwarring vandaan komt. Ik ga ervanuit dat iedere developer sourcecontrol gebruikt namelijk, dat is m.i. niet optioneel.

[Sardaukar]

Tja, toch zie ik maar al te vaak dat developers wel source control gebruiken maar dan alleen maar als een veredelde back-up tool waarmee men een paar versies terug kan. Concepten als branchen / mergen worden nog (IMHO) te weinig gebruikt.

[Soultaker]

Zelf zou ik dit met Git oplossen: één branch waar je de upstream releases trackt, en één branch met daarin jouw wijzigingen. Als je de release branch updatet, kun je je changes porten met git rebase. Ouderwetse RCS's zoals CVS en Subversion kunnen dat niet, voor zover ik weet, maar andere moderne systemen (Mercurial?) waarschijnlijk wel. De reden dat ik Git zou pakken is dat ik daar al wat ervaring mee heb, maar daar heb jij niets aan.

Het is in ieder geval nuttig om te bedenken wat de gewenste workflow precies is. Eigenlijk wil je jouw changes representeren als patch, die je elke keer weer applied op de laatste upstream release. Dat is ook precies wat git rebase doet. Je kan dat natuurlijk ook handmatig met diff en patch doen, maar dan mis je een aantal geavanceerde features om te mergen, als de patch niet 100% geapplyd kan worden.