SVN revisie van working copy

[Zeezicht]

Ik gebruik voor het ontwikkelen SVN voor het versiebeheer. Maar nu wil ik weten wat de revisie is van een working copy.
Dit is dan vooral van belang als ik deze gedeployed heb op zijn definitieve plek. Als er dan later een fout in zit en ik wil de changes tussen die revisie en de huidige zien (bijv. of de DB veranderd is) dan weet ik vanaf welke revisie ik moet kijken.
Ik wil dus automatisch in een bestand het revisie nummer zetten. Nu kan dat met properties gedeeltijk, want een propertie wordt alleen verandert als het bestand ook verandert. En dat is nou juist iets wat niet gebeurt, maar wel andere bestanden worden aangepast.

Heeft iemand hier een oplossing voor?

[blaataaps]

Vertellen svn log -r HEAD en/of svn info in de root van je working copy niet precies wat je wil?

[ Voor 11% gewijzigd door blaataaps op 12-04-2007 14:00 ]

[ReverendBizarre]

SVN werkt niet met repository revisions zoals CVS dat doet. Revisions worden in SVN alleen per bestand bijgehouden. Als je daadwerkelijk een versie gaat deployen is het dus het handigste om daarvan een tag te maken. Je kan dan altijd een diff tussen die tag en je huidige trunk/working copy doen om te kijken wat de verschillen zijn (je moet dan natuurlijk nog wel bijhouden welke tag je hebt gedeployed).

[Erkens]

CAIRATH schreef op donderdag 12 april 2007 @ 13:46:
SVN werkt niet met repository revisions zoals CVS dat doet. Revisions worden in SVN alleen per bestand bijgehouden.

Waarschijnlijk bedoel je andersom
CVS is revision per file, SVN per reposititory

[Zeezicht]

blaataaps schreef op donderdag 12 april 2007 @ 13:40:
Vertellen svn log -R HEAD en/of svn info in de root van je working copy niet precies wat je wil?

Nou ik verwijder bij het deployen alle .svn dir's. Dus het is geen werkende working copy meer. Dan kan ik dus niet meer dingen gaan opvragen ervan. En HEAD geeft de laatste revisie in de repository weer, dus dat zou 'm dan ook niet zijn. Eerder BASE ofzo?

CAIRATH schreef op donderdag 12 april 2007 @ 13:46:
SVN werkt niet met repository revisions zoals CVS dat doet. Revisions worden in SVN alleen per bestand bijgehouden. Als je daadwerkelijk een versie gaat deployen is het dus het handigste om daarvan een tag te maken. Je kan dan altijd een diff tussen die tag en je huidige trunk/working copy doen om te kijken wat de verschillen zijn (je moet dan natuurlijk nog wel bijhouden welke tag je hebt gedeployed).

Mmm zo'n tags is wel een goed idee eigenlijk. Ook al zijn het soms maar kleine wijzigingen waarvoor je nou niet echt een nieuwe release tag wilt aanmaken. Maar kan ik dan nog steeds niet automatisch ergens die versie (revisie) neerzetten?

[kenneth]

Waarom wil je geen release tag maken? Tags zijn cheap

[blaataaps]

Zeezicht schreef op donderdag 12 april 2007 @ 13:55:
[...]

Nou ik verwijder bij het deployen alle .svn dir's. Dus het is geen werkende working copy meer. Dan kan ik dus niet meer dingen gaan opvragen ervan.

Dan moet je niet in je topicstart zeggen dat je de revisie van je working copy wil weten, als je geen working copy hebt. En als je handmatig al die .svn-dingen weggooit kan ik je ook aanraden gewoon svn export te gebruiken.

En HEAD geeft de laatste revisie in de repository weer, dus dat zou 'm dan ook niet zijn. Eerder BASE ofzo?

Maar kan ik dan nog steeds niet automatisch ergens die versie (revisie) neerzetten?

Als je geen tag wil maken, kun je in plaats van een simpele svn export of checkout,

code:

svn export URL | tail -n 1 > checkedoutversion.txt

doen of iets dergelijks, afhankelijk van het platform waar je op werkt.

[ Voor 18% gewijzigd door blaataaps op 12-04-2007 14:12 ]

[sam.vimes]

Zeezicht schreef op donderdag 12 april 2007 @ 13:34:
Ik gebruik voor het ontwikkelen SVN voor het versiebeheer. Maar nu wil ik weten wat de revisie is van een working copy.

Een working-copy kan uit een combinatie van meerdere revisies bestaan. Ieder bestand kan afkomstig zijn uit een andere revisie van de repository. Om de revisies van alle bestanden in een working-copy gelijk te trekken, geef je het commando

code:

svn update

De versie kun je vervolgens opvragen met

code:

svnversion

Zie

code:

svnversion --help

en http://svnbook.red-bean.c...03.html#svn-ch-2-sect-3.4

Een betere oplossing is een tag maken; daarmee maak je een snapshot van de working-copy waarin je ontwikkelt. Vanuit de top-dir van je working-copy geeft je het commando:

code:

svn copy . svn://machine/repository/tags/Release2007-04-12

ervan uitgaande dat je de standaard repository-indeling (met /trunk, /tags en /branches) hebt aangehouden.

[Zeezicht]

kenneth schreef op donderdag 12 april 2007 @ 14:04:
Waarom wil je geen release tag maken? Tags zijn cheap

Dat klopt ook wel, maar ik verwacht dan een enorme lijst met tags te krijgen. Maakt het niet echt overzichtelijker, dus die wil ik eigenlijk voorbehouden aan grote releases.

blaataaps schreef op donderdag 12 april 2007 @ 14:07:
[...]
Dan moet je niet in je topicstart zeggen dat je de revisie van je working copy wil weten, als je geen working copy hebt. En als je handmatig al die .svn-dingen weggooit kan ik je ook aanraden gewoon svn export te gebruiken.

Oeps sorry hoor En ik ga idd natuurlijk die .svn dir's niet handmatig verwijderen...

blaataaps schreef op donderdag 12 april 2007 @ 14:07:
Als je geen tag wil maken, kun je in plaats van een simpele svn export of checkout,

code:

svn export URL | tail -n 1 > checkedoutversion.txt

doen of iets dergelijks, afhankelijk van het platform waar je op werkt.

Dit is wel een goed idee. Zo weet ik precies welke versie er staat en die export kan ik zo automatiseren bij mijn andere commando's die nog uitgevoerd moeten worden.

[MisterData]

Als je persé je Subversion-repository-versie in je bestanden wil zetten (om later precies te kunnen zien van welke versie het bestand is) dan kun je keywords gebruiken (zie hier onderaan)

[Zeezicht]

MisterData schreef op donderdag 12 april 2007 @ 15:15:
Als je persé je Subversion-repository-versie in je bestanden wil zetten (om later precies te kunnen zien van welke versie het bestand is) dan kun je keywords gebruiken (zie hier onderaan)

Maar dat wijzigt ie alleen in bestanden die je ook wijzigt, dus dat was hier geen optie.

[The - DDD]

Het plaatsen van "tags" in de tag directory is enkel een advies.

Wie zegt dat jij niet in de tag map een submap "oldtags" aan kan maken?

Of een Main tag met daaronder subtags?

tag/versie1/versie1.0.1
tag/versie1/versie1.0.2
tag/versie1/versie1.0.3
tag/versie2/versie2.0.1

[kenneth]

Of gewoon tijdelijke tags weer wissen ...

[Mc.Boldy]

en let op... het aanmaken van een tag leidt tot een nieuwe rev. nummer.

[kenneth]

En met het bijhouden van tags wordt het revnr doorgaans weer minder belangrijk

[misfire]

Wat je wilt is het magische "$GlobalRev$" keyword waar in de nightly versie van de svn docs naar gerefereerd wordt bij keyword substitution (staat niet in de eerder gelinkte 1.0 versie van de svn docs). Wat sam.vimes al eerder beschreef is wat je wilt weten: de "svnversion" tool. Als je kijkt naar die output dan snap je ook waarom het keyword niet bestaat: het global revision number kan niet betrouwbaar per enkel bestand worden bepaald.

Puur als identificatie van een bepaalde status van de repository is een global revision number prima. Het is uniek, automatisch en kan niet worden gewijzigd. Je kunt altijd achteraf bepalen hoe de gehele repo er op dat moment uitzag. Technisch gezien is dat goed genoeg.

Een versie heeft wel logische voordelen: je hebt een kapstok waar je dingen aan op kunt hangen. Bijvoorbeeld: voor versie x.y is deze feature gepland. In deze versie zit deze bug. Versie a.b gaat over 4 weken in productie. Eén of ander magisch technisch nummer is niet zo praktisch als communicatiemiddel. Als je een development cycle hebt met gedefinieerde milestones en -overgangen dan zijn versies gewoon handiger, en als je dan toch een versie af hebt, maak er dan meteen een tag van.