Vi har allerede dekket i detalj hvordan Subversion lagrer og henter diverse versjoner av filer og kataloger i depotet. Hele kapitler er viet til disse mest fundamentale delene av funksjonalitet som verktøyet har. Og hvis versjoneringsmulighetene stoppet der, ville Subversion fortsatt være komplett sett fra et versjonskontrollsynspunkt.
Men det stopper ikke der.
I tillegg til å versjonere kataloger og filer, har Subversion grensesnitt for å legge til, forandre og fjerne versjonerte metadata på alle versjonerte kataloger og filer. Vi refererer til disse metadataene som egenskaper (engelsk: properties), og du kan tenke på dem som en tabell med to kolonner som forbinder egenskapsnavn med vilkårlige verdier som ligger sammen med hvert element i arbeidskopien din. Generelt sett kan navnene og verdiene til egenskapene være hva du vil at de skal være, med den begrensningen at navnene må være lesbar for mennesker. Og det beste med disse egenskapene er at de også er versjonerte, akkurat som det tekstbaserte innholdet i filene dine. Du kan forandre, legge inn og reversere egenskapsforandringer like lett som å legge inn forandringer i innhold. Og sending og henting av egenskapsforandringer blir en del av dine vanlige innleggingsoperasjoner – du trenger ikke å forandre på rutinene for å få det til.
Egenskaper finnes også andre steder i Subversion. Akkurat som filer og kataloger kan ha vilkårlige egenskapsnavn og verdier vedlagt, kan hver revisjon som helhet ha vilkårlige egenskaper lagt ved. De samme begrensningene gjelder også her – navnene må være lesbare for mennesker, men verdiene kan være binære og alt hva du vil. Hovedforskjellen er at revisjonsegenskaper ikke er versjonerte. Med andre ord, hvis du forandrer verdien på, eller sletter, en revisjonsegenskap, er det ingen funksjonalitet i Subversion for å sette den tilbake til den forrige verdien.
Subversion har ingen spesiell policy angående bruken av
egenskaper.
Alt Subversion ber om er at du ikke bruker egenskapsnavn som
begynner med forstavelsen svn:.
Det er det navnerommet som er reservert for egen bruk.
Og Subversion bruker faktisk egenskaper, både av den versjonerte
og uversjonerte typen.
Enkelte versjonerte egenskaper har spesiell betydning eller effekt
når de brukes på filer og kataloger, eller lagrer spesiell
informasjon om revisjonene de finnes i.
Enkelte revisjonsegenskaper legges automatisk til revisjoner av
innleggingsprosessen, og inneholder informasjon om revisjonen.
Mesteparten av disse egenskapene er nevnt andre steder andre
steder i dette eller andre kapitler som del av de mer generelle
emnene de hører til.
For en fyldig liste over Subversions forhåndsdefinerte egenskaper,
se Subversion-defined properties.
I denne seksjonen vil vi studere nyttigheten – både for Subversionbrukere og Subversion selv – av støtte for egenskaper. Du vil lære om de egenskapsrelaterte svn-delkommandoene og hvordan forandring av egenskaper påvirker den normale arbeidsflyten i Subversion. Forhåpentligvis vil du bli overbevist om at Subversionegenskaper kan forbedre bruken din av versjonskontroll.
Akkurat som Subversion bruker egenskaper for å lagre ekstra informasjon om filer, kataloger og revisjoner som den inneholder, kan du også få god bruk for egenskaper. Noen deler av prosessene rundt bruken din av Subversion, eller kanskje tilleggsprogrammer til Subversion som du bruker, kan få nytte av å ha en plass nær dine versjonerte data der du kan legge spesialsydde metadata om disse dataene.
Tenk deg at du vil sette opp en hjemmeside som inneholder mange digitale bilder, og viser dem med tittel og tidspunkt. Fotosamlingen forandrer seg i ett sett, så du vil helst automatisere så mye som mulig. Disse bildene kan være ganske store, så du vil i likhet med andre hjemmesider av denne typen vise miniatyrbilder til de besøkende.
Nå kan du saktens oppnå denne effekten ved å bruke
tradisjonelle filer.
Det vil si at du kan ha bildet bilde123.jpg
og en bilde123-mini.jpg side ved side i en
katalog.
Eller hvis du vil bruke det samme filnavnet, kan du ha
miniatyrbildene i en annen katalog, for eksempel
mini/bilde123.jpg.
Du kan også lagre titlene og tidspunktene på en lignende måte,
separert fra den originale bildefila.
Men problemet her er at samlingen din av filer vokser noe
voldsomt for hvert nytt bilde som blir lagt til
hjemmesida.
Så kan du se for deg den samme hjemmesida lagt opp på en
måte som bruker Subversions filegenskaper.
Tenk deg å ha en enkelt bildefil,
bilde123.jpg, med egenskaper på denne fila
som er kalt tittel,
tidspunkt og miniatyr.
Nå ser arbeidskopien din mye mer oversiktlig ut – faktisk ser
det med en vanlig nettleser ut som det bare er bildefiler i den.
Men de automatiserte skriptene dine vet bedre.
De vet at de kan bruke svn (eller enda bedre,
de kan bruke språkbindingene i Subversion – se “Using Languages Other than C and C++”) for å hente ut
den ekstra informasjonen som hjemmesida trenger for å vise
bildet uten å måtte lese en indeksfil eller trikse med
filstier.
Spesialsydde revisjonsegenskaper blir også ofte brukt.
En vanlig bruksmåte er en egenskap der verdien inneholder en ID
fra en feildatabase som revisjonen er assosiert med, kanskje
fordi forandringen i den revisjonen ordner en feil som er logget
i feildatabasen med den ID-en.
Andre bruksmåter kan være å legge ved mer brukervennlige navn i
revisjonen – det kan være vanskelig å huske at revisjon 1935 var
en gjennomtestet revisjon.
Men hvis det er, la oss si, en
testresultat-egenskap på den revisjonen med
en verdi som Alt OK, er det god informasjon å
ha.
svn-kommandoen har flere måter å legge til og modifisere fil- og katalogegenskaper. For egenskaper med korte egenskaper som er leselig for folk flest, er kanskje den enkleste måten å legge til en ny egenskap å spesifisere navnet på egenskapen med verdien dens på kommandolinja med propset-delkommandoen.
$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c Egenskapen «copyright» satt på «calc/button.c» $
Men vi har fremhevet fleksibiliteten som Subversion har for
egenskapsverdier.
Og hvis du har en tekstbasert, eller til og med binær
egenskapsverdi som går over flere linjer, vil du sannsynligvis
ikke oppgi denne verdien på kommandolinja.
Derfor kan propset-delkommandoen bruke valget
--file (-F) for å spesifisere
navnet på en fil som inneholder den nye verdien til
egenskapen.
$ svn propset license -F /sti/til/LISENS calc/button.c Egenskapen «license» satt på «calc/button.c» $
Det er noen restriksjoner på navnene du kan bruke på
egenskaper.
Et egenskapsnavn må starte med en bokstav, kolon
(:) eller understrek (_).
Etter dette kan du også bruke siffer, bindestrek
(-) og punktum
(.).[8]
I tillegg til propset-kommandoen, har svn-programmet kommandoen propedit. Denne kommandoen bruker tekstbehandleren som er spesifisert i konfigurasjonen (se “Konfigurasjon”) for å legge til eller modifisere egenskaper. Når du kjører kommandoen, kjører svn tekstbehandleren mot en midlertidig fil som inneholder den nåværende verdien til egenskapen (eller starter uten tekst hvis du legger til en ny egenskap). Deretter forandrer du på verdien i tekstbehandleren til den er lik den nye verdien du vil lagre i egenskapen, lagrer den midlertidige fila og avslutter tekstbehandleren. Hvis Subversion finner ut at du faktisk har forandret den nåværende egenskapsverdien, vil den godta det som den nye verdien til egenskapen. Hvis du avslutter tekstbehandleren uten å gjøre noen forandringer, vil det ikke bli gjort noen forandringer i egenskapen.
$ svn propedit copyright calc/button.c ### tekstbehandleren avsluttes uten at noe er forandret Ingen endring for egenskap «copyright» på «calc/button.c» $
Vi skal legge merke til at i likhet med andre svn-kommandoer kan de som har med egenskaper å gjøre utføre handlinger på flere stier på en gang. Dette lar deg forandre egenskaper på hele sett av filer med en enkelt kommando. For eksempel kunne vi ha gjort dette:
$ svn propset copyright '(c) 2006 Red-Bean Software' calc/* Egenskapen «copyright» satt på «calc/Makefile» Egenskapen «copyright» satt på «calc/button.c» Egenskapen «copyright» satt på «calc/integer.c» … $
Alt dette med å legge til og redigere egenskaper hadde egentlig ikke vært særlig nyttig hvis du ikke hadde hatt en måte å få tak i den lagrede egenskapsverdien. Til dette har svn-programmet to delkommandoer for å vise navnene og verdiene til egenskaper som er lagret i filer og kataloger. Kommandoen svn proplist vil liste ut navnene på egenskapene som eksisterer i en sti. Når du vet navnene til egenskapene på noden, kan du be om verdiene individuelt ved å bruke svn propget. Denne kommandoen vil, når den får en sti (eller sett av stier) og et egenskapsnavn, skrive verdien av egenskapen til standard ut-strømmen.
$ svn proplist calc/button.c Egenskaper for «calc/button.c»: copyright license $ svn propget copyright calc/button.c (c) 2006 Red-Bean Software
Det er til og med en variant av
proplist-kommandoen som vil liste både navnet
og verdien til alle egenskapene.
Bare legg til valget --verbose
(-v).
$ svn proplist --verbose calc/button.c Egenskaper for «calc/button.c»: copyright : (c) 2006 Red-Bean Software license : ================================================================ Copyright (c) 2006 Red-Bean Software. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the recipe for Fitz's famous red-beans-and-rice. …
Den siste delkommandoen relatert til egenskaper er propdel. Siden Subversion lar deg lagre egenskaper med tomme verdier, kan du ikke fjerne en egenskap helt ved å bruke propedit eller propset. For eksempel, denne kommandoen vil ikke gjøre det du ønsker:
$ svn propset license '' calc/button.c Egenskapen «license» satt på «calc/button.c» $ svn proplist --verbose calc/button.c Egenskaper for «calc/button.c»: copyright : (c) 2006 Red-Bean Software license : $
Du må bruke propdel-delkommandoen for å fjerne egenskaper helt. Syntaksen er lik de andre egenskapskommandoene:
$ svn propdel license calc/button.c Egenskapen «license» slettet fra «calc/button.c». $ svn proplist --verbose calc/button.c Egenskaper for 'calc/button.c': copyright : (c) 2006 Red-Bean Software $
Husker du de uversjonerte revisjonsegenskapene?
Du kan modifisere disse også ved hjelp av de samme
delkommandoene for svn som vi nettopp
beskrev.
Bare legg til --revprop-valget på kommandolinja
og spesifiser revisjonen for den egenskapen du vil forandre.
Siden revisjoner er globale, trenger du ikke å spesifisere en
målsti sammen med disse egenskapsrelaterte kommandoene så lenge
du er i en arbeidskopi fra depotet som har revisjonsegenskapen
du vil forandre.
Ellers kan du oppgi URLen for en hvilken som helst sti i depotet
det gjelder (inkludert depotets rotadresse).
Du vil for eksempel erstatte loggmeldingen for en eksisterende
revisjon.[9]
Hvis den nåværende katalogen er en del av en arbeidskopi fra
depotet ditt, kan du ganske enkelt kjøre kommandoen svn
propset uten å spesifisere en målsti:
$ svn propset svn:log '* button.c: Fjerna en kompilatoradvarsel.' -r11 --revprop Egenskapen «svn:log» satt på depotrevisjon «11» $
Men selv om du ikke har hentet ut en arbeidskopi fra depotet, kan du fortsatt forandre egenskapen ved å oppgi URLen til depotroten:
$ svn propset svn:log '* button.c: Fjerna en kompilatoradvarsel.' -r11 --revprop \
http://svn.example.com/depot/prosjekt
Egenskapen «svn:log» satt på depotrevisjon «11»
$
Legg merke til at muligheten til å forandre disse uversjonerte egenskapene må settes spesielt av depotadministratoren (se “Påhakningsskript”). Siden egenskapene ikke er versjonerte, risikerer du å miste informasjon hvis du ikke er forsiktig når du redigerer. Depotadministratoren kan sette opp metoder for å beskytte mot datatap som dette, og standardoppsettet forbyr forandringer i revisjonsegenskaper.
Brukere bør, der det er mulig, bruke svn propedit istedenfor svn propset. Selv om sluttresultatet er identisk, vil førstnevnte la dem se den nåværende verdien av egenskapen som de er i ferd med å forandre, noe som hjelper dem å kontrollere at de faktisk gjør den endringen som de tror de gjør. Dette gjelder spesielt for modifisering av uversjonerte revisjonsegenskaper. I tillegg er det betraktelig enklere å redigere egenskaper som strekker seg over flere linjer i en tekstbehandler enn på kommandolinja.
Nå som du er kjent med alle svn-kommandoene som er relatert til egenskaper, la oss se hvordan forandringer i egenskaper påvirker den vanlige arbeidsflyten i Subversion. Som vi nevnte tidligere, er fil- og katalogegenskaper versjonerte, akkurat som innholdet i filene dine. Dette betyr at Subversion har de samme mulighetene for fletting – med dertil potensielle konflikter – av andres forandringer inn i dine egne.
Og i likhet med filinnhold, er forandringene dine i egenskapene lokale modifiseringer som kun blir gjort permanente når du legger dem inn i depotet med svn commit. Egenskapsforandringene kan lett omgjøres – kommandoen svn revert vil sette filene og katalogene dine tilbake til den uredigerte tilstanden – innhold, egenskaper, alt. Du kan også få interessant informasjon om tilstanden til fil- og katalogegenskapene ved å bruke kommandoene svn status og svn diff.
$ svn status calc/button.c M calc/button.c $ svn diff calc/button.c Egenskapsforandringer på: calc/button.c ___________________________________________________________________ Navn: copyright + (c) 2006 Red-Bean Software $
Legg merke til hvordan
status-delkommandoen viser
M i den andre kolonnen istedenfor den første.
Det er fordi vi har forandret egenskapene på
calc/button.c, men ikke forandret
tekstinnholdet.
Hadde vi forandret begge to, ville det også vært en
M i den første kolonnen (se “svn status”).
Du har kanskje lagt merke til den smårare måten Subversion viser forskjeller i egenskaper på. Du kan fortsatt kjøre svn diff og omdirigere resultatet for å lage en gyldig patchfil. patch-programmet vil imidlertid ignorere patcher for egenskaper – alle data som det ikke forstår vil bli ignorert. Dette betyr dessverre at for å patche egenskaper med en fil laget av svn diff, må forandringer i egenskaper legges til for hånd.
Properties are a powerful feature of Subversion, acting as key components of many Subversion features discussed elsewhere in this and other chapters—textual diff and merge support, keyword substitution, newline translation, etc. But to get the full benefit of properties, they must be set on the right files and directories. Unfortunately, that can be a step easily forgotten in the routine of things, especially since failing to set a property doesn't usually result in an obvious error condition (at least compared to, say, failing to add a file to version control). To help your properties get applied to the places that need them, Subversion provides a couple of simple but useful features.
Whenever you introduce a file to version control using the
svn add or svn import
commands, Subversion tries to assist by setting some common
file properties automatically. First, on operating systems
whose filesystems support an execute permission bit,
Subversion will automatically set the
svn:executable property on newly added or
imported files whose execute bit is enabled. (See “File Executability” for more
about this property.) Secondly, it runs a very basic
heuristic to determine if that file contains human-readable
content. If not, Subversion will automatically set the
svn:mime-type property on that file to
application/octet-stream (the generic
“this is a collection of bytes” MIME type). Of
course, if Subversion guesses incorrectly, or if you wish to
set the svn:mime-type property to something
more precise—perhaps image/png or
application/x-shockwave-flash—you can
always remove or edit that property. (For more on
Subversion's use of MIME types, see “File Content Type”.)
Subversion also provides, via its runtime configuration
system (see “Konfigurasjonsområdet for bruk under kjøring”), a more
flexible automatic property setting feature which allows you
to create mappings of filename patterns to property names and
values. Once again, these mappings affect adds and imports,
and not only can override the default MIME type decision made
by Subversion during those operations, but can also set
additional Subversion or custom properties, too. For example,
you might create a mapping that says that any time you add
JPEG files—ones that match the pattern
*.jpg—Subversion should automatically
set the svn:mime-type property on those
files to image/jpeg. Or perhaps any files
that match *.cpp should have
svn:eol-style set to
native, and svn:keywords
set to Id. Automatic property support is
perhaps the handiest property related tool in the Subversion
toolbox. See “Konfigurasjon” for more about
configuring that support.