Versie controle systeem

[H!GHGuY]

We zijn op het werk op zoek naar een alternatief voor CVS. Nu zijn we bezig met evalueren van enkele VCS'en zoals SVN, Git, Mercurial, Perforce en ClearCase (wat binnen het bedrijf de default is).

We zitten echter met 1 belangrijke use-case die gesupporteerd moet blijven, maar die binnen andere VCS'en misschien niet kan:
Het product bestaat uit meerdere deelprojecten (~executables) die apart uitgecheckt kunnen worden.
Binnen zo'n deelproject wordt ook geregeld dezelfde code gebruikt (framework code bvb) en die wordt dan ook telkens uitgecheckt binnen dat project. bvb:

Local	CVS
ProjectX/Framework/ModuleX	Framework/ModuleX
ProjectX/Framework/ModuleY	Framework/ModuleY
ProjectX/Software/ModuleZ	ProjectX/Software/ModuleZ

Dit doen we door middel van scripts en files die beschrijven hoe en wat moet uitgecheckt worden. Bovendien is het zo dat framework modules tags dragen en altijd op de trunk verblijven terwijl software modules gebrancht worden per release.

Nu blijkt SVN bijvoorbeeld externals te hebben, maar bij een test vonden we dat als beperking hebben dat framework modificaties bij een commit niet automatisch meegenomen worden, wat toch een belangrijke beperking is.
Ook andere VCS'en hebben dergelijke features (zie Wikipedia: Comparison of revision control software), maar we kunnen ons misschien wel wat tijd besparen door even beroep te doen op ervaringen van anderen.

Daarnaast hebben we natuurlijk nog enkele andere wensen zoals atomic commits, behoud van CVS history bij overgang, enz... maar bovenstaande use-case (of een degelijk alternatief met redelijke backwards compatibility) is toch redelijk kritisch.

Welk "modern" versiebeheer systeem (behalve CVS natuurlijk) supporteert zo'n use-cases op een vlotte manier, of hoe kunnen we dergelijke functionaliteit bereiken met een ander VCS?

[mithras]

Ik snap niet precies je uitleg dat svn :externals niet werkt.

Ik heb een project A
Ik heb een project B met op /library de property :exterals "LibraryA pad/naar/projectA"

Ik verander wat in project A en doe een commit. Ik doe een update van project B en zie de nieuwe dingen, ook van A, binnengehaald worden. Of wil je dat als je in projectB/library/projectA een bestand gaat wijzigen, dit direct ook in de repository van project A wordt meegenomen?

Dat is (geloof ik) iets wat wel mogelijk is, maar slechts met de juiste instellingen (correct me if I'm wrong).

[Cartman!]

In SVN kun je inderdaad dergelijke zaken instellen, gewoon downloaden die hap en proberen zou ik zeggen. Eigenlijkt komt t erop neer dat je op Wikipedia gelezen hebt dat het wel kan maar je hebt t niet getest dus

Gewoon de pro's en con's voor ieder systeem neerzetten, je afvragen wat jullie ermee willen kunnen en dan die gebruiken.

[H!GHGuY]

mithras schreef op dinsdag 03 november 2009 @ 19:47:
Of wil je dat als je in projectB/library/projectA een bestand gaat wijzigen, dit direct ook in de repository van project A wordt meegenomen?

Dat is (geloof ik) iets wat wel mogelijk is, maar slechts met de juiste instellingen (correct me if I'm wrong).

Juist, dat is wat we willen. Als je in ProjectX/Framework/ModuleX iets wijzigt dat je die wijzigingen dan automatisch bij een svn commit/diff vanuit ProjectX ziet.
En zoals ik aanhaalde in de TS hebben we bij een kleine test gezien dat dit niet, althans niet by default, gebeurt. De persoon die testte is echter iets bekender met SVN en wist ook niet of dit kon.

Daarnaast kunnen we inderdaad elk systeem gaan testen en dat is uiteindelijk ook de bedoeling, maar daar kruipt veel tijd in. We moeten telkens een snapshot van onze CVS proberen importeren en daar dan iets zinnigs mee gaan doen. Daarnaast hebben we het probleem dat we met onze korte testen slechts een beperkte vergelijking kunnen doen. Alles ten gronde testen zou vereisen dat je iemand een week per systeem geeft. Daarom vraag ik naar ervaringen met de VCS'en van mensen die er dagelijks mee werken zodat we beter geinformeerd onze keuze kunnen maken...

[Janoz]

Om eerlijk te zijn vind ik het nogal een gevaarlijke manier van werken. Vooral omdat iedereen in dezelfde trunk van het framework blijkbaar aanpassingen kan doen is er geen enkele controle op wat voor invloed dit heeft op andere projecten. Alleen lopende projecten hebben een kans dat het opgemerkt wordt omdat er actief aan ontwikkeld wordt, maar hoe is dat met al afgeronde projecten?

Het lijkt mij juist veel voor de hand liggender om ook het framework te branchen zodra er een aanpassing in gedaan moet worden. Het mergen van deze aanpassing met de trunk is vervolgens een duidelijk gedefinieerde actie waarbij de nodige controles uitgevoerd kunnen worden.

[user109731]

Mercurial heeft dit sinds 1.3 in de core (voorheen via de Forest extension). Helaas nog wel experimenteel.
Afaik worden commits in subrepos gewooon recursief uitgevoerd.

Mercurial werkt heel fijn, maar als je van CVS komt sluit SVN misschien beter aan...

[Janoz]

Sorry, maar zodra ik ook maar ergens een vleugje 'expirimenteel' of 'beta' tegenkom dan valt het wat mij betreft af bij de keuze voor een VCS. Leuk voor de (grotere) hobby projecten, maar meer ook niet.

[H!GHGuY]

Janoz schreef op woensdag 04 november 2009 @ 10:20:
Om eerlijk te zijn vind ik het nogal een gevaarlijke manier van werken. Vooral omdat iedereen in dezelfde trunk van het framework blijkbaar aanpassingen kan doen is er geen enkele controle op wat voor invloed dit heeft op andere projecten. Alleen lopende projecten hebben een kans dat het opgemerkt wordt omdat er actief aan ontwikkeld wordt, maar hoe is dat met al afgeronde projecten?

Daarvoor dienen de tags. Elk project refereert naar een tag/versie van elke framework module. Nieuwe aanpassingen worden dus niet automatisch doorgedrukt in andere projecten. Voor onze eigen projecten worden de framework tags tijdens elke nachtelijke build geupdate naar de laatste. We weten dus dagelijks of we breaking changes hebben gecommit. Daarnaast kunnen we dit meestal wel inschatten.
Bij elke release worden de framework tags voor die release gefreezed. Dit wil zeggen dat de automatische updates vervallen en enkel manuele updates nog kunnen.

Het lijkt mij juist veel voor de hand liggender om ook het framework te branchen zodra er een aanpassing in gedaan moet worden. Het mergen van deze aanpassing met de trunk is vervolgens een duidelijk gedefinieerde actie waarbij de nodige controles uitgevoerd kunnen worden.

We weten dat ons systeem niet ideaal is, maar het is op dit moment het "minst slechte" wegens nog enkele constraints op andere vlakken.

Zoals Janoz aanhaalt is experimenteel niet echt ons keyword. We willen ook niet elke 3 maand een nieuwe versie moeten installeren om bugs op te lossen of data-loss te fixen wegens "experimenteel". Een stabiel pakket is echt een kritische vereiste, het is en blijft een productie omgeving.

[Janoz]

De grootste vraag die dan eigenlijk nog overblijft is:

Waarom willen jullie van CVS af?

[user109731]

Experimenteel slaat vooral op de commando's voor het maken van subrepos. De core en het repository formaat zelf zijn uiteraard rock-solid. Maar okee, point taken.

Waarom willen jullie van CVS af?

Omdat je een bejaard VCS zonder atomic commits imho ook niet in productie wil? CVS heeft verder geen globaal revision number en bij een rename verlies je je history. Leuk voor de (grotere) hobby projecten, maar ik snap wel dat de TS er vanaf wil.

[Janoz]

Ik ben benieuwd naar de reden van de topicstarter zelf. Bejaard is bijvoorbeeld ook te vervangen door bewezen .

[H!GHGuY]

Omdat we meer en meer in de knoei raken met branches en merges. We willen naar een systeem waarin merge-tracking beter verloopt (lees: welke merge tracking heeft). Daarnaast hebben we nog een hele reeks wensen zoals atomic commits, enz.

Het probleem is dat we nu typisch een 3tal actieve releases hebben. Het heen en weer mergen van changes wordt hierbij stilaan een werk op zich. Vroeger beperkte zich dit meestal tot max 2. Van hier dus de start van de zoektocht.

[eek]

H!GHGuY schreef op woensdag 04 november 2009 @ 10:04:
[...]

Juist, dat is wat we willen. Als je in ProjectX/Framework/ModuleX iets wijzigt dat je die wijzigingen dan automatisch bij een svn commit/diff vanuit ProjectX ziet.

Ik heb dit net even getest op een lokaal svn repository. Als je iets wijzigt in je external dan zie je dit bij de als je gaat commiten in de root. Als je die wijziging dan wil commiten moet je naar die directory toe gaan en vanaf daar de commit uit voeren.

[H!GHGuY]

eek schreef op woensdag 04 november 2009 @ 20:50:
[...]
Ik heb dit net even getest op een lokaal svn repository. Als je iets wijzigt in je external dan zie je dit bij de als je gaat commiten in de root. Als je die wijziging dan wil commiten moet je naar die directory toe gaan en vanaf daar de commit uit voeren.

Liever in 1 maal dus. Maar dat is nu ook nog niet onoverkomelijk. Ik had echter wel ook verstaan dat je die changes bij een svn diff ook per module manueel moet gaan bekijken.

[eek]

H!GHGuY schreef op donderdag 05 november 2009 @ 09:27:
[...]

Liever in 1 maal dus. Maar dat is nu ook nog niet onoverkomelijk. Ik had echter wel ook verstaan dat je die changes bij een svn diff ook per module manueel moet gaan bekijken.

Ik dacht eerst ook dat dit wel handig zou zijn, maar je zal toch per project bij een commit een omschrijving moeten geven. De aanpassingen die je in je module maakt zou je niet terug moeten zijn bij de history van je framework.

[H!GHGuY]

Daar heb je een punt. Die diff over alles heen is echter wel handig.

Subversion is, gezien we van CVS komen, het eerste pakket dat we testen dus daar komen we wel uit. Zeker ook omdat er toch enkele mensen wel iets meer SVN kennis hebben.
Nog interessanter vind ik het ook om te weten hoe de andere pakketten hiermee omgaan. Mercurial kent het wel maar daar is de functie nog niet stable, git kent zoiets als submodules maar die vind ik (van wat ik in de manual lees) niet echt gebruiksvriendelijk en van de andere VCS'en heb ik nog geen idee of we er zelfs iets mee kunnen.

Het lijkt me dat we toch mogelijk een moeilijk migratie tegemoet gaan als we al een pakket vinden dat aan al onze noden/wensen voldoet.