[Mercurial] (Automatisch) lokaal patchen van subrepositories

[Fuzzillogic]

Voor m'n software, zie het als een library, gebruik ik Mercurial als SCM. Voor elk van m'n projecten waarbij ik de library gebruik maak ik een nieuwe repository en voeg daar de library als subrepository aan toe. So far so good.

In principe wil ik voorkomen dat ik de library moet aanpassen voor één specifiek project, maar soms ontkom je er niet aan. Als je die aanpassingen direct in de (lokale) subrepository uitvoert dat die aanpassingen meteen ook gecommit en later gepusht worden naar de repository van de library zelf. Dat is niet de bedoeling, want dan zouden die specifieke aanpassingen uiteindelijk toch doorgevoerd worden naar álle projecten waar de library gebruikt wordt.

Wat ik dus zou willen is dat project-specifieke aanpassingen in de library alleen worden opgeslagen in de repository van het project zelf. Daarbij wil ik wél de mogelijkheid behouden om de library te updaten uit de standaard library-repository.

De queues-extensie zou perfect voldoen voor deze situatie, ware het niet dat deze géén subrepositories ondersteunt

Dus: hoe kan ik het beste omgaan met project-specifieke aanpassingen op een subrepository in Mercurial?

[Jan_V]

Ben ook wel benieuwd naar het antwoord hoe dit in Mercuarial opgelost kan worden.

Even out of the box:
Je zou natuurlijk nog een extra project er bij kunnen maken met dezelfde namespace als je library en daarin je wijzigingen maken voor dit specifieke project. Zo houdt je de library schoon en kun je toch de specifieke wijzigingen gebruiken.
Wellicht dat je dan wat inheritance, hiding en andere dingen moet toepassen om alles precies goed te krijgen, maar zo zou je het via code al kunnen doen denk ik.

Ga hier even uit van een .NET project, zal wellicht ook in Java werken. PHP ben ik niet bekend mee.

[H!GHGuY]

Het lijkt mij also je een bad design/implementation decision wil laten fixen door je SCM.

Als iets specifiek is voor 1 project, dan hoort het niet in de library thuis. Is iets niet specifiek voor 1 project, dan hoor je het gewoon generiek te maken voor alle projecten.

Project-specifieke code in een (fork van een) shared-lib stoppen en dan je SCM forceren om alles op te lossen is gewoon not-done.

[Fuzzillogic]

H!GHGuY schreef op donderdag 10 maart 2011 @ 10:50:
Het lijkt mij also je een bad design/implementation decision wil laten fixen door je SCM.

Als iets specifiek is voor 1 project, dan hoort het niet in de library thuis. Is iets niet specifiek voor 1 project, dan hoor je het gewoon generiek te maken voor alle projecten.

Project-specifieke code in een (fork van een) shared-lib stoppen en dan je SCM forceren om alles op te lossen is gewoon not-done.

Dat vind ik te kort door de bocht. Soms heb je gewoon te maken met hele specifieke aanpassingen. Klanten willen immers soms de gekste dingen. Je kunt dan álles wel configurabel maken, maar dat wordt al snel een puinhoop, qua settings en qua code. Soms wordt code daar ook alleen maar onnodig traag door.

Soms moet het ook gewoon gisteren klaar zijn en is er geen tijd of budget om het fancy te doen.

Soms heb je ook alleen maar clone-rechten op de library. Je kunt dan uiteraard wel je eigen fork met daarin extra config-dingen gaan bijhouden, maar dat maakt het er beslist ook niet makkelijk op als je je source code weer wilt verspreiden.

Soms is de "configuratieoptie" er wel, maar in de form van een #define in een header-file.

Het is gewoon een afweging van de developer. Een systeem dat aanpassingen aan de subrepos als patches in de parent-repos bijhoudt lijkt mij een prima oplossing voor veel gevallen. Precies wat Queues doet. Maar dan voor subrepositories...

[Woy]

Mocht je echt een wijziging in je Library willen maken die alleen specifiek voor dat project is dan zul je IMHO de library moeten branchen. Eventuele wijzigingen in de main branch zal je dan moeten mergen met jouw specifieke branch.

Maar ik ben het tot op bepaalde hoogte eigenlijk wel met H!GHGuY eens dat je eigenlijk in een library beter kunt zorgen dat je funcitonaliteit optioneel toevoegt, en er zo voor zorgt dat het niks breekt voor de andere projecten, dan om specifieke wijzigingen te gaan doen voor 1 project. Immers kom je dan altijd met het probleem te zitten dat je meerdere versies van de library moet gaan onderhouden.

[Fuzzillogic]

Branchen is imo een slechte optie voor one-of-modifications. Afgezien van de overhead van het handmatig mergen zul je ergens een clone van de library moeten hebben die al die branches bijhoudt, wat ook weer overhead is.

Juist door patches op de library alleen in de project-repos op te slaan voorkom je meteen dat je ooit iets breekt voor andere projecten; die hebben immers geen weet van die patches.

[ Voor 3% gewijzigd door Fuzzillogic op 10-03-2011 13:40 ]

[Woy]

Fuzzillogic schreef op donderdag 10 maart 2011 @ 13:40:
Juist door patches op de library alleen in de project-repos op te slaan voorkom je meteen dat je ooit iets breekt voor andere projecten; die hebben immers geen weet van die patches.

Ik ben niet bekend met Mecurial, maar in principe is je project-repos natuurlijk gewoon een lokale branch/clone van je centrale library. Je zult dan dus moeten zorgen dat je nooit van die branch dingen terug naar de central repo pusht, maal alleen nieuwe wijzigingen pull't. Is het probleem dan dat dat pushen automatisch gaat? Dat lijkt mij enigszins vreemd, in bijvoorbeeld GIT zul je zelf aan moeten geven dat er gepushed word.

Maar als het dergelijk kleine one-off wijzigingen zijn, vraag ik me eigenlijk af waarom je die extra functionaliteit niet gewoon optioneel maakt in je library. Op het moment dat je toch alleen in je project die wijzigingen wil hebben, zul je hoe dan ook het probleem blijven houden dat je meerdere versies moet onderhouden, hoe klein de verschillen ook zijn.

[Fuzzillogic]

Woy schreef op donderdag 10 maart 2011 @ 13:57:
[...]

Ik ben niet bekend met Mecurial, maar in principe is je project-repos natuurlijk gewoon een lokale branch/clone van je centrale library. Je zult dan dus moeten zorgen dat je nooit van die branch dingen terug naar de central repo pusht, maal alleen nieuwe wijzigingen pull't. Is het probleem dan dat dat pushen automatisch gaat? Dat lijkt mij enigszins vreemd, in bijvoorbeeld GIT zul je zelf aan moeten geven dat er gepushed word.

Het gaat hier specifiek om subrepositories. Wijzigingen in de library, de subrepos, worden idd automatisch gepusht. Soms handig, meestal niet, maar op zich te voorkomen.

Wellicht dat Git hier een stuk beter mee omgaat. Het lijkt er meer en meer op dat voor Mercurial hier geen duidelijke oplossing voor is, wat me ook erg verbaast.

Maar als het dergelijk kleine one-off wijzigingen zijn, vraag ik me eigenlijk af waarom je die extra functionaliteit niet gewoon optioneel maakt in je library. Op het moment dat je toch alleen in je project die wijzigingen wil hebben, zul je hoe dan ook het probleem blijven houden dat je meerdere versies moet onderhouden, hoe klein de verschillen ook zijn.

Ik wil de library niet "vervuilen" met elke blurp waar klanten soms mee komen. Klanten willen soms de vreemdste dingen, waarvan je je als developer afvraagt "wtf? Waarom??". Maarja, klant betaalt er goed voor, dus hey, why should I care?

Updaten is niet echt een issue. Als versie n van de library goed werkt in het project, dan ga ik niet onnodig updaten naar versie n+x. Mocht dat toch nodig zijn, dan is de kans groot dat de losse patches prima te applyen zijn op die versie n+x.

Again, dat is eigenlijk zoals Queues werken.

[djc]

Ik denk toch dat branches van je library hier de beste optie voor zijn. Ook conceptueel gezien is het tenslotte een branch.

Wat je nog zou kunnen bekijken is een queue maken voor je library. Deze kun je eventueel ook weer als hg repository behandelen (zie bijvoorbeeld qcommit).