Hoe hangt jouw SVN repos in elkaar?

[TheBlasphemer]

Ik heb momenteel een drietal projecten in mijn (persoonlijke) SVN server hangen:

• A/trunk = hoofdproject waar ik het meeste aan werk
• A/branches/eensuffeupdate = hoofdproject poging tot aan de praat krijgen met nieuwe software
• B = rewrite van hoofdproject voor bovengenoemde nieuwe software
• C = library die vanuit A/branches/eensuffeupdate en B wordt gebruikt.

Echter is het nu een grote spaghetti geworden:

• C gebruikt een tooltje dat bij A zit
• Dit tooltje heeft in A/branches/eensuffeupdate een aantal verbeteringen gekregen, maar is nog niet teruggemerged naar A/trunk.
• In A zitten veel meer tooltjes die niet direct gerelateerd zijn aan project A, en ik later misschien wel in B nodig zal hebben.

Ik ben van plan een apart project te maken voor alle tooltjes, of zelfs een apart project voor elk tooltje. Echter ben ik bang dat ik dan over een jaar weer tegen een grote rotzooi aanloop omdat ik dan weer iets over het hoofd heb gezien.

Vandaar de vraag: Hoe hebben jullie je SVN repositories georganiseerd? en hoe zou je mij adviseren om te herstructureren?

[leuk_he]

Als er tussen de tooltjes een afhangelijkheid zit met A/B/C (database struktuur ofzo) dan helpt reoganisere niet echt. Dan heb je tooltsjes/flows nodig om de verschillende bomen in sync te houden.

Dode boompjes zo snel mogeijk snoeien.

Ik heb nog geen ervaringen met goede versiebeheer toosl die verschillende bomen / release pakketten doen, maar wat ik heb gelezen is juist een tool als http://bazaar-vcs.org/ hier erg geschikt voor is om verschillende versies te syncen.

[Creepy]

@leuk_he: SVN kan zelf ook prima verschillende branches syncen, dat heet gewoon "MERGE". Je kan dan prima wijzigingen uit branche X halen en die in branche Y laten doorvoeren. Daar heb je echt geen dvcs voor nodig.

Zijn A, B en C nu verschillende repositories of zit dat in 1 repository? Als ze echt met elkaar te maken hebben dan lijkt me het handiger om dat in 1 repository te houden. Als het echt totaal losse projecten zijn dan natuurlijk los.

Maar het feit dat je in je source losse tooltjes hebt zitten die niet nodig zijn en project C een tool uit A nodig heeft duidt meer op een probleem met de structuur van je broncode, niet van de structuur van je versiebeheersysteem.

[muksie]

Als ik in een project code uit een andere SVN tree nodig heb, voeg ik die in met een svn:externals property. Misschien dat dat iets voor je is?

[leuk_he]

Creepy schreef op vrijdag 17 oktober 2008 @ 11:51:
@leuk_he: SVN kan zelf ook prima verschillende branches syncen, dat heet gewoon "MERGE". Je kan dan prima wijzigingen uit branche X halen en die in branche Y laten doorvoeren. Daar heb je echt geen dvcs voor nodig.

Maar hoe bepaal welke mergesets bij elkaar horen? ((DB wijzingen + tool 1 wijziging + tool2 wijzinging.). Hoe regel je dat?

[Creepy]

Diezelfde vraag heb je bij een DVS toch ook? Branches in SVN zijn goedkoop, het is niet meer dan een database wijziging voor de niet gewijzigde files. Kleine moeite om voor een specifieke wijzigingen een branche of een tag te maken en die in z'n geheel te mergen waar nodig. Met een DVCS zul je ook moeten weten welke veranderingen je nodig hebt.

[djc]

Creepy schreef op vrijdag 17 oktober 2008 @ 14:21:
Diezelfde vraag heb je bij een DVS toch ook? Branches in SVN zijn goedkoop, het is niet meer dan een database wijziging voor de niet gewijzigde files. Kleine moeite om voor een specifieke wijzigingen een branche of een tag te maken en die in z'n geheel te mergen waar nodig. Met een DVCS zul je ook moeten weten welke veranderingen je nodig hebt.

Verschil is wel dat een DVCS zelf al nauwkeurig bijhoudt welke wijzigingen ergens inzitten. Dit is pas in Subversion 1.5 enigszins aangepakt (en daarvoor in svnmerge.py), maar veel minder vergaand dan bij een DVCS (ik heb voornamelijk ervaring met Mercurial).

In Mercurial is van elke changeset expliciet bekend welke andere changesets zijn meegenomen, wat mergen echt een stuk makkelijker maakt (en de integriteit bevordert).

[Confusion]

TheBlasphemer schreef op vrijdag 17 oktober 2008 @ 11:29:
Ik ben van plan een apart project te maken voor alle tooltjes, of zelfs een apart project voor elk tooltje. Echter ben ik bang dat ik dan over een jaar weer tegen een grote rotzooi aanloop omdat ik dan weer iets over het hoofd heb gezien.

Niet bang zijn en gewoon de veranderingen doorvoeren. Meestal evolueert zo'n situatie door verschillende refactorings langzaam naar een betere situatie. Het is nu onwerkbaar; je eerste zorg is dus het nu werkbaar te krijgen. Niet teveel tijd besteden aan wat je denkt dat je misschien ooit in de toekomst nodig zou kunnen hebben.

Vandaar de vraag: Hoe hebben jullie je SVN repositories georganiseerd? en hoe zou je mij adviseren om te herstructureren?

Je probleem heeft niet met SVN organisatie te maken, maar met software organisatie. Als jij op een gegeven moment denkt dat een bepaalde set compilation units een losse library zou moeten vormen, dan splits je die uit. Of dat een losse library binnen project A is of een nieuw project B moet vormen, is een beslissing die daar los van staat.