[ALG] SVN en versienummering

[pkouwer]

Ik ben me een beetje aan het verdiepen in SVN (i.c.m. Turtoise), heb al e.e.a. gelezen in de manual en op internet, maar ik zit met een issue waar ik maar niet uitkom:

ik heb, volgens de manual van SVN, op een virtuele machine (puur ter test) een SVN installatie gedaan en een repository gemaakt. Op mijn ontwikkelbak Turtoise geinstalleerd, geconnect en wat bestanden gemaakt/gewijzigd etc. Dit gaat allemaal goed. Althans voor 1 project. Ik zie de HEAD-revision netjes oplopen zoals dat hoort. Maar nu heb ik een tweede project, totaal anders, andere klant etc. Nu wil ik niet dat de versienummering van project A de "teller" ophoogt van project B.

Hoe kan ik dit het beste/eenvoudigste oplossen ?

[Leftblank]

Wanneer je per project een losse repository gebruikt zullen die elkaar niet beinvloeden. Ook is het wel handig om een onderscheid te maken tussen versienummers en revisienummers (welke je met svn ophoogt); je zal waarschijnlijk niet in alle gevallen bij elke commit per se het versienummer op willen hogen lijkt mij.

[pkouwer]

dus als ik het goed begrijp moet ik per project een repository maken op de server (straks dus...) met

svnadmin create "c:\Documents and Settings\project 1"
svnadmin create "c:\Documents and Settings\project 2"
svnadmin create "c:\Documents and Settings\project 3"
...

.

ik mijn ontwikkelomgeving "connect" ik dan naar
svn://ip-addres/project 1
svn://ip-addres/project 2
svn://ip-addres/project 3

[Verwijderd]

pkouwer schreef op zondag 17 juli 2011 @ 18:27:
dus als ik het goed begrijp moet ik per project een repository maken op de server (straks dus...) met

svnadmin create "c:\Documents and Settings\project 1"
svnadmin create "c:\Documents and Settings\project 2"
svnadmin create "c:\Documents and Settings\project 3"
...

.

ik mijn ontwikkelomgeving "connect" ik dan naar
svn://ip-addres/project 1
svn://ip-addres/project 2
svn://ip-addres/project 3

Dat is het idee, ja.

[xzaz]

Zoek eens op: Branch en trunks. Dat systeem is ons aangeleerd en ik gebruik dat naar alle tevredenheid. In het begin wat veel werk om op te zetten maar het is zeker de moeite waard.

[Nick_S]

Misschien wil je wel alles in 1 repository zetten. Als jij later code wil verplaatsen naar algemene modules is dat met meerdere repositories erg lastig en zal je dus je history kwijt raken. Binnen 1 repository is code veel makkelijker te verplaatsen.

Dus:

code:

svnadmin create c:/repository
svn mkdir file:///c:/repository/project1 file:///c:/repository/project1/trunk file:///c:/repository/project1/branches file:///c:/repository/project1/tags
svn mkdir file:///c:/repository/project2 file:///c:/repository/project2/trunk file:///c:/repository/project2/branches file:///c:/repository/project2/tags
svn mkdir file:///c:/repository/common1 file:///c:/repository/common1/trunk file:///c:/repository/common1/branches file:///c:/repository/common1/tags

svn co file:///c:/repository/project1
svn co file:///c:/repository/project2
svn co file:///c:/repository/common1

Kijk bijvoorbeeld eens naar de Apache repository, welke nu op revisie 1147681 zit. SVN kan dit makkelijk aan.

[ Voor 8% gewijzigd door Nick_S op 17-07-2011 18:52 ]

[Voutloos]

En maak je vooral niet te druk als je revisienummer een keertje omhoog gaat, het is maar een tellertje. Pas als het nummer opeens omlaag gaat mag je in de stress schieten.

[Big4SMK]

Ik denk dat je de begrippen versie en revisie door elkaar haalt.

Wat je in principe aan je klant geeft is een versienummer, bijvoorbeeld 2.0. Het revisie nummer is vaak puur voor intern gebruik, en kan dus prima de 32158ste commit zijn.
Je kan dan een "tag" aan revisie 32158 hangen met "v2.0" o.i.d. waardoor je je totaal niet druk hoeft te maken om een commit meer of minder.

Wat ik zelf vaak doe met svn is branchen op het moment dat je een versie de deur uit doet. Ik maak dan een branch "2.0" en ga verder in de trunk voor versie "3.0". Het voordeel daarvan is dat je altijd nog een hotfix voor accute problemen in branch 2.0 kunt maken, zonder dat je rekening hoeft te houden met de (expirimentele/halfwerkend/brakke) code die je alvast voor 3.0 gecommit hebt.

(overigens...als je svn een nieuwe hobby is...kijk dan ook eens naar GiT, dat is in mijn ogen superieur aan svn)

[pkouwer]

als ik me geen zorgen hoef te maken over revisienummers en klanten dit niet te zien krijgen, dan denk ik dat ik alles in 1 repos zet.

Over de versienummers zelf, kent SVN deze ook zelf toe of is dit op eigen initiatief/inzicht ?

[xzaz]

pkouwer schreef op zondag 17 juli 2011 @ 19:36:
als ik me geen zorgen hoef te maken over revisienummers en klanten dit niet te zien krijgen, dan denk ik dat ik alles in 1 repos zet.

Over de versienummers zelf, kent SVN deze ook zelf toe of is dit op eigen initiatief/inzicht ?

Nee dit moet je zelf doen, verschillende versie nummers revisions nummers van configuratieitems (CI) worden tot een release uitgewerkt (versie). Deze CI's maken dus je product. Het handige is hieraan dat elke afdeling zijn eigen afzonderlijke CI heeft en dat je hieraan ook rechten kunt hangen.
Uiteindelijk ben jij als release manager dus verantwoordelijk voor wat jouw product wordt. Deze zet je in een branch en noem je v 1.0, wijzigingen worden v.1.1 welke je ook weer in je trunk wijzigt.
Zo kan je dus ook releases (lees: bepaalde versies) laten vervallen voor support.

[Kettrick]

xzaz schreef op zondag 17 juli 2011 @ 19:45:
[...]

Nee dit moet je zelf doen

Niets moet

Onze CI ( continious integration ) omgeving plakt voor elke build een nummertje achter het versienummer in het project. Concreet betekend dat dat maven 0.1.2-SNAPSHOT omgecat wordt naar 0.1.2.455 voor revisie 455.

Deze versies blijven binnen de dev omgeving, zodra wij er bij mee zijn drukken we op de knop en gaan dezelfde artifects uiteindelijk naar productie.

Er zijn oneindig veel mogelijkheden

[JKVA]

Kettrick schreef op zondag 17 juli 2011 @ 20:28:
[...]


Niets moet

Onze CI ( continious integration ) omgeving plakt voor elke build een nummertje achter het versienummer in het project. Concreet betekend dat dat maven 0.1.2-SNAPSHOT omgecat wordt naar 0.1.2.455 voor revisie 455.

Deze versies blijven binnen de dev omgeving, zodra wij er bij mee zijn drukken we op de knop en gaan dezelfde artifects uiteindelijk naar productie.

Er zijn oneindig veel mogelijkheden

Om een idee te krijgen hoe je een beetje slim je project kunt releasen, zie de docs van de Apache Maven Release Plugin.

Stap 1: Prepare: (http://maven.apache.org/p...ples/prepare-release.html)

Preparing a release goes through the following release phases:

• Check that there are no uncommitted changes in the sources
• Check that there are no SNAPSHOT dependencies
• Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
• Transform the SCM information in the POM to include the final destination of the tag
• Run the project tests against the modified POMs to confirm everything is in working order
• Commit the modified POMs
• Tag the code in the SCM with a version name (this will be prompted for)
• Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
• Commit the modified POMs

Stap 2: Perform: (http://maven.apache.org/p...ples/perform-release.html)

• Checkout from an SCM URL with optional tag
• Run the predefined Maven goals to release the project (by default, deploy site-deploy)

Lang verhaal kort, Maven hoogt het versienummer in je source code (pom.xml bestand) op, commit het en maakt een tag. Onder die tag staat de huidige status van je project op het moment van releasen. Daarna wordt (met perform) de tag uitgechecked en worden de binaries gebuild.

Maven is trouwens bedoeld voor Java projecten, maar het principe achter deze release is ook prima toe te passen op andere (PHP, ASP, whatever) projecten.

Oh nog iets, Apache heeft naast SVN ook een GIT repository. GIT is (net als Mercurial, een alternatief voor GIT) een gedistribueerd versiebeheersysteem. Als ik jou was zou ik meteen met GIT of Mercurial beginnen. Persoonlijk prefereer ik Mercurial, omdat ik zowel Windows als Mac draai en de Windows GIT client niet super is. Van GIT/Mercurial terugstappen op SVN is makkelijk, maar andersom is lastiger.

[pkouwer]

tot slot laatste vraag waar ik nog wel mee zit:

ik heb nu op mijn laptop de meeste projecten staan (div. talen, SQL-scripts etc), die ik met regelmaat backup naar onze server. Als er met mijn laptop iets mis gaat, ben ik in principe geen (of weinig) data verloren. Stel dat ik met SVN aan de slag ga, dan heb ik in feite alleen een werkdirectory. Deze kan ik in principe dat nog steeds backuppen, maar kan ik ook de SNV repository backuppen en wel zo dat ik er, mocht het misgaan, hier nog iets aan heb of ben ik dan totaal verloren....

[Nick_S]

Je SVN repository kun je gewoon zippen/copieren en later weer gebruiken, zolang er niemand op dat moment commit. Anders moet je even naar svnadmin hotcopy kijken voordat je kan zippen/copieren.

[xzaz]

Uiteindelijk is het altijd een bedrijfsregel hoe je er mee omgaat, het is ook een stukje gewenning Zo lang je het zelf maar kan verantwoorden waarom je het zo doet is het prima.

[ Voor 28% gewijzigd door xzaz op 17-07-2011 21:11 ]

[Verwijderd]

Ik heb geen ervaring met git; wel met subversion. Wat ik hab begrepen van de git handleiding is dat je daar geen centrale repository hebt -- iedere gebruiker heeft een locale repository en een eigen repository op de server. Ik kan zien hoe zo'n opzet goed werkt bij een project als de Linux kernel (een hoop contributors, waarbij uiteindelijk uit iedere repository een deel van de wijzigingen wordt overgenomen en gemerged tot een nieuwe versie). Maar hoe zou je zoiets opzetten voor een meer standaard kantooromgeving, waar het meestal wel wenselijk is dat je een centrale repository hebt? Gaat dat niet in tegen het principe van git?

[Kettrick]

JKVA schreef op zondag 17 juli 2011 @ 20:43:
[...]

Om een idee te krijgen hoe je een beetje slim je project kunt releasen, zie de docs van de Apache Maven Release Plugin.

Stap 1: Prepare: (http://maven.apache.org/p...ples/prepare-release.html)

Stap 2: Perform: (http://maven.apache.org/p...ples/perform-release.html)

Lang verhaal kort, Maven hoogt het versienummer in je source code (pom.xml bestand) op, commit het en maakt een tag. Onder die tag staat de huidige status van je project op het moment van releasen. Daarna wordt (met perform) de tag uitgechecked en worden de binaries gebuild.

Dat is de reguiere manier, maar zorgt ervoor dat je al je releases in zowel je svn als artifact repository hebt, iets wat wij niet voor elke build willen, vandaar onze werkwijze .

Wij doen nu :

• Versie patch
• Artifacts bouwen
• Deployen op dev omgeving
• Handmatig goedkeuren, eens per week/paar dagen normaal gesproken
• Uploaden artifacts
• Taggen in svn repo ( omdat het moet, in principe niet nodig )

Onze manier is een stuk sneller en heeft hetzelfde resultaat.

Maven is trouwens bedoeld voor Java projecten, maar het principe achter deze release is ook prima toe te passen op andere (PHP, ASP, whatever) projecten.

Oh nog iets, Apache heeft naast SVN ook een GIT repository. GIT is (net als Mercurial, een alternatief voor GIT) een gedistribueerd versiebeheersysteem. Als ik jou was zou ik meteen met GIT of Mercurial beginnen. Persoonlijk prefereer ik Mercurial, omdat ik zowel Windows als Mac draai en de Windows GIT client niet super is. Van GIT/Mercurial terugstappen op SVN is makkelijk, maar andersom is lastiger.

Ik gebruik zelf bazaar als SVN client, eenieder die de mogelijkheid heeft om SVN te dumpen moet dat wat mij betreft vooral doen . De svn/git/bazaar oorlog is bij ons ook uitgebroken

[Voutloos]

pkouwer schreef op zondag 17 juli 2011 @ 20:56:
ik heb nu op mijn laptop de meeste projecten staan (div. talen, SQL-scripts etc), die ik met regelmaat backup naar onze server. Als er met mijn laptop iets mis gaat, ben ik in principe geen (of weinig) data verloren. Stel dat ik met SVN aan de slag ga, dan heb ik in feite alleen een werkdirectory. Deze kan ik in principe dat nog steeds backuppen, maar kan ik ook de SNV repository backuppen en wel zo dat ik er, mocht het misgaan, hier nog iets aan heb of ben ik dan totaal verloren....

Eenvoudig en negeer alle antwoorden die niet _minstens_ het volgende omvatten, aangezien het de #1 prof. devven regel is:
alles dat je maakt en gebruikt moet in je versiebeheer systeem EN van dit systeem moeten, net als elk systeem met data dat iets waard, backups zijn.

Uitzonderingen op deze regel bedenken == iedereen een plezier doen en een andere hobby zoeken.

[ Voor 5% gewijzigd door Voutloos op 17-07-2011 22:34 ]

[ValHallASW]

Verwijderd schreef op zondag 17 juli 2011 @ 22:01:
Maar hoe zou je zoiets opzetten voor een meer standaard kantooromgeving, waar het meestal wel wenselijk is dat je een centrale repository hebt? Gaat dat niet in tegen het principe van git?

Heel simpel: een centrale repository opzetten en die gebruiken (== pushen / pullen vanaf elke client). Zie bv. github. Dat het niet hoeft betekent niet dat het niet kan (en ook niet dat het niet mag ;-)).

[pkouwer]

Voutloos schreef op zondag 17 juli 2011 @ 22:33:
[...]
...

Uitzonderingen op deze regel bedenken == iedereen een plezier doen en een andere hobby zoeken.

beetje kort door de bocht. Uitzonderingen kunnen er best zijn, mits goed gedocumenteerd, afgesproken en nageleefd. Om dan meteen een andere hobby te zoeken....