[svnbook commit] r1523 - in trunk/src/nb: . book
sunny256
svnbook-dev at red-bean.com
Wed Jul 6 04:10:48 CDT 2005
Author: sunny256
Date: Wed Jul 6 04:10:46 2005
New Revision: 1523
Modified:
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch04.xml
Log:
Finished proofreading of ch04.xml in the Norwegian svnbook.
* src/nb/TRANSLATION-STATUS
Remove "partial" status of ch04.xml .
* src/nb/book/ch04.xml
Tweaks, corrections and beautifying.
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Wed Jul 6 04:10:46 2005
@@ -79,7 +79,7 @@
book/ch01.xml
book/ch02.xml
book/ch03.xml
- book/ch04.xml (line 2495, 59%)
+ book/ch04.xml
$Id$
vim: set tw=72 nowrap et sw=2 ts=2 sts=2 fo+=2w fenc=utf8 :
Modified: trunk/src/nb/book/ch04.xml
==============================================================================
--- trunk/src/nb/book/ch04.xml (original)
+++ trunk/src/nb/book/ch04.xml Wed Jul 6 04:10:46 2005
@@ -2510,8 +2510,9 @@
<foreignphrase>changesets</foreignphrase>).
Ved å bruke <option>-r</option>-valget kan du be <command>svn
merge</command> om å legge inn et forandringssett, eller et helt
- område av forandringssett, vi ber <command>svn merge</command>
- om å legge inn forandringssett nummer 303
+ område av forandringssett, til arbeidskopien din.
+ I vårt tilfelle med å omgjøre en forandring ber vi <command>svn
+ merge</command> om å legge inn forandringssett nummer 303
<emphasis>baklengs</emphasis> inn i arbeidskopien vår.</para>
<!-- @ENGLISH {{{
@@ -2531,9 +2532,8 @@
deg om at arbeidet ditt er i den tilstanden du vil det skal være
i, og deretter bruke <command>svn commit</command> for å sende
den endelige versjonen til depotet.
- <!-- ¤ Den engelske setninga der er kanskje litt uklar? -->Etter
- innleggingen er dette spesielle forandringssettet ikke lenger
- representert i <literal>HEAD</literal>-revisjonen.</para>
+ Etter innleggingen er dette spesielle forandringssettet ikke
+ lenger representert i <literal>HEAD</literal>-revisjonen.</para>
<!-- @ENGLISH {{{
<para>Again, you may be thinking: well, that really didn't undo
@@ -2583,8 +2583,8 @@
I de fleste situasjoner er dette greit nok.
De fleste er bare interessert i å følge <literal>HEAD</literal>
av et prosjekt uansett.
- Det er imidlertid spesielle tilfeller du virkelig vil ødelegge
- alle spor etter innleggingen, kanskje la noen inn et
+ Det er imidlertid spesielle tilfeller der du virkelig vil
+ ødelegge alle spor etter innleggingen, kanskje la noen inn et
konfidensielt dokument ved en ulykke.
Dette er ikke så lett, viser det seg, fordi Subversion ble
spesielt designet for å aldri miste informasjon.
@@ -2592,13 +2592,14 @@
Det å fjerne en revisjon fra historien vil forårsake en
dominoeffekt som vil føre til kaos i alle etterfølgende
revisjoner og muligens gjøre alle arbeidskopiene
- ubrukelige.<footnote><para>Subversionprosjektet har imidlertid
- planer om å legge inn en <command>svnadmin
- obliterate</command>-kommando som vil ta seg av oppgaven med å
- permanent slette informasjon.
- I mellomtiden, se <xref
- linkend="svn.reposadmin.maint.tk.svndumpfilter"/> for en mulig
- omvei om problemet.</para></footnote></para>
+ ubrukelige.<footnote>
+ <para>Subversionprosjektet har imidlertid planer om å legge
+ inn en <command>svnadmin obliterate</command>-kommando som
+ vil ta seg av oppgaven med å permanent slette informasjon.
+ I mellomtiden, se <xref
+ linkend="svn.reposadmin.maint.tk.svndumpfilter"/> for en
+ mulig omvei om problemet.</para>
+ </footnote></para>
</sect2>
@@ -2667,12 +2668,12 @@
perhaps via an incremental search in an editor).</para>
@ENGLISH }}} -->
<para>Subversion har ingen <filename>Attic</filename>-katalog som
- CVS har,<footnote><para>Fordi CVS ikke versjonerer trær, lager
- den et <filename>Attic</filename>-område innenfor hver
- depotkatalog som en måte å huske slettede filer
- på.</para></footnote>
- så du må bruke <command>svn log</command> for å finne det
- eksakte koordinatparet som du vil hente tilbake.
+ CVS har,<footnote>
+ <para>Fordi CVS ikke versjonerer trær, lager den et
+ <filename>Attic</filename>-område innenfor hver depotkatalog
+ som en måte å huske slettede filer på.</para>
+ </footnote> så du må bruke <command>svn log</command> for å
+ finne det eksakte koordinatparet som du vil hente tilbake.
En god strategi er å kjøre <command>svn log --verbose</command>
i en katalog som inneholdt det slettede elementet ditt.
Valget <command>--verbose</command> viser en liste over alle
@@ -2758,9 +2759,9 @@
Dette vil ha samme effekten som å legge til
<filename>real.c</filename> en gang til som en lokal
modifisering.
- Filen vil bli klargjort for tillegging, og etter at du sender
- det inn til depotet med <command>svn commit</command>, vil filen
- atter en gang eksistere i <literal>HEAD</literal>.</para>
+ Filen vil bli klargjort for tillegging, og etter en innlegging
+ med <command>svn commit</command> vil filen eksistere i
+ <literal>HEAD</literal> igjen.</para>
<!-- @ENGLISH {{{
<para>In this particular example, however, this is probably not
@@ -2782,8 +2783,8 @@
<filename>integer.c</filename>, noe som du ikke ønsker.
Du kan selvfølgelig bakoverflette revisjon 808 og deretter kjøre
<command>svn revert</command> på de lokale forandringene i
- <filename>integer.c</filename>, men denne teknikken <!-- ¤
- -->skalerer ikke alltid like bra.
+ <filename>integer.c</filename>, men denne teknikken skalerer
+ ikke alltid like bra.
Hva hvis det var 90 filer som forandret seg i revisjon
808?</para>
@@ -2794,16 +2795,16 @@
revision and path <quote>coordinate pair</quote> from the
repository to your working copy:</para>
@ENGLISH }}} -->
- <para>En annen og mer <!-- ¤ -->målbevisst strategi er å ikke
- bruke <command>svn merge</command> i det hele tatt, men derimot
+ <para>En annen og mer målrettet strategi er å ikke bruke
+ <command>svn merge</command> i det hele tatt, men derimot
<command>svn copy</command>.
Kopier ganske enkelt den eksakte revisjonens og stiens
<quote>koordinatpar</quote> fra depotet til arbeidskopien
din:</para>
- <!-- ¤ -->
+ <!-- @ENGLISH {{{
<screen>
-$ svn copy --revision 807 \
+$ svn copy -ﳢ-revision 807 \
http://svn.example.com/repos/calc/trunk/real.c ./real.c
$ svn status
@@ -2814,6 +2815,19 @@
Transmitting file data .
Committed revision 1390.
</screen>
+ @ENGLISH }}} -->
+ <screen>
+$ svn copy --revision 807 \
+ http://svn.example.com/repos/calc/trunk/real.c ./real.c
+
+$ svn status
+A + real.c
+
+$ svn commit -m "Hentet tilbake real.c from revisjon 807, /calc/trunk/real.c."
+Adding real.c
+Transmitting file data .
+Committed revision 1390.
+</screen>
<!-- @ENGLISH {{{
<para>The plus sign in the status output indicates that the item
@@ -2875,9 +2889,9 @@
Hvis du ikke bruker Subversion til programutvikling, kan du
hoppe over denne seksjonen.
Hvis du er en programutvikler som bruker versjonskontroll for
- første gang, følg nøye med, da disse fremgangsmåtene ofte blant
- erfarne brukere er ansett som de beste metodene.
- Disse prosessene er ikke spesifikke til Subversion;
+ første gang, følg nøye med, da disse fremgangsmåtene blant
+ erfarne brukere ofte er ansett som de beste metodene.
+ Disse prosessene er ikke spesifikke for Subversion;
de kan brukes med ethvert versjonskontrollsystem.
Men det kan hjelpe å se dem beskrevet i
Subversionterminologi.</para>
@@ -2978,7 +2992,7 @@
et annet team fortsetter på nytt arbeid (for eksempel på det
som skal bli versjon 2.0) i <filename>/trunk</filename>.
Hvis det blir funnet feil på et av stedene, blir
- reparasjoner flettet fram og tilbake så mye som nødvendig.
+ nødvendige reparasjoner flettet fram og tilbake.
Men på et punkt stopper også denne prosessen.
Grenen er <quote>frosset</quote> for avsluttende testing
rett før en utgivelse.</para>
@@ -2998,8 +3012,8 @@
Når testingen er ferdig, blir
<filename>/branches/1.0</filename> kopiert til
- <filename>/tags/1.0.0</filename> som et referansebilde.
- Merket pakkes og utgitt til kundene.</para>
+ <filename>/tags/1.0.0</filename> som et referanseøyeblikksbilde.
+ De merkede filene pakkes og sendes ut til kundene.</para>
</listitem>
<listitem>
@@ -3021,10 +3035,10 @@
versjon 2.0, blir fortsatt feil som blir funnet på
<filename>/trunk</filename> flettet derfra til
<filename>/branches/1.0</filename>.
- Når et tilstrekkelig antall feil er blitt rettet, bestemmer
- vedlikeholderne seg for å lage en 1.0.1-utgivelse:
+ Når et tilstrekkelig antall feil er blitt rettet, kan
+ vedlikeholderne bestemme seg for å lage en 1.0.1-utgivelse:
<filename>/branches/1.0</filename> blir kopiert til
- <filename>/tags/1.0.1</filename>, og merket blir pakket og
+ <filename>/tags/1.0.1</filename>, og de merkede filene blir pakket og
utgitt.</para>
</listitem>
@@ -3071,9 +3085,9 @@
å arbeide på <filename>/trunk</filename>.
Det er en midlertidig gren som er opprettet for å arbeide på
en kompleks forandring uten å la det gå ut over stabiliteten
- til <filename>Trunk</filename>.
- I motsetning til utgivelsesgrener (som må bli støttet for
- alltid) blir funksjonalitetsgrener født, brukt en stund,
+ til <filename>/trunk</filename>.
+ I motsetning til utgivelsesgrener (som kanskje må bli støttet
+ for alltid) blir funksjonalitetsgrener født, brukt en stund,
flettet tilbake til <filename>trunk</filename>, og deretter
til sist slettet.
De har en begrenset nyttighetsperiode.</para>
@@ -3110,7 +3124,7 @@
kort levetid, nøye kontrollert og deretter flettet til trunk.
Så blir grenen slettet.
Dette systemet garanterer en eksepsjonelt stabil og brukbar
- trunk til enhver tid, men til en pris i form av mer arbeid i
+ trunk til enhver tid, men med en pris i form av mer arbeid i
prosessen.</para>
<!-- @ENGLISH {{{
@@ -3153,9 +3167,9 @@
development differ so greatly that it may become a nightmare
trying to merge the branch back to the trunk.</para>
@ENGLISH }}} -->
- <para>Til sist har vi saken med hvordan man best kan holde en
- fremtidig gren i <quote>synk</quote> med trunk etterhvert som
- arbeidet går fram.
+ <para>Til sist har vi spørsmålet om hvordan man best kan holde
+ en fremtidig gren i <quote>synk</quote> med trunk etterhvert
+ som arbeidet går fram.
Som vi nevnte tidligere, er det en stor risiko å arbeide på en
gren i flere uker eller måneder; forandringer på trunk kommer
strømmende inn, til punktet der de to utviklingslinjene er
@@ -3228,7 +3242,7 @@
</screen>
@ENGLISH }}} -->
<screen>
-$ cd trunk-working-copy
+$ cd trunk-i-arbeidskopien
$ svn update
At revision 1910.
@@ -3237,8 +3251,8 @@
http://svn.example.com/repos/calc/branches/mybranch@1910
U real.c
U integer.c
-A newdirectory
-A newdirectory/newfile
+A nykatalog
+A nykatalog/nyfil
…
</screen>
@@ -3251,8 +3265,8 @@
@ENGLISH }}} -->
<para>Ved å sammenligne <literal>HEAD</literal>-revisjonen for
trunk med <literal>HEAD</literal>-revisjonen på grenen, kan du
- definere et delta som beskriver kun de forandringene som du
- gjorde til grenen; begge utviklingsgrener har allerede
+ definere ett delta som beskriver kun de forandringene som du
+ gjorde til grenen; begge utviklingsgrener inneholder allerede
forandringene fra trunk.</para>
<!-- @ENGLISH {{{
@@ -3273,7 +3287,7 @@
<emphasis>er</emphasis> jo en arbeidskopi en grunn, privat
gren.
Det er en gren som bare er i stand til å lagre én forandring
- på en gang.</para>
+ om gangen.</para>
</sect3>
@@ -3301,7 +3315,7 @@
<filename>/calc/trunk</filename> to mirror the new branch
location:</para>
@ENGLISH }}} -->
- <para>Kommandoen <command>svn switch</command> forandrer en
+ <para>Kommandoen <command>svn switch</command> flytter en
eksisterende arbeidskopi til en annen gren.
Selv om denne kommandoen strengt tatt ikke er nødvendig for å
arbeide med forgreninger, gir den en fin snarvei for brukere,
@@ -3340,8 +3354,8 @@
<para>Etter å ha <quote>byttet om</quote> til grenen, er ikke
arbeidskopien mer forskjellig enn om du hadde gjort en fersk
uthenting av katalogen.
- Og det er vangligvis med praktisk å bruke denne kommandoen, fordi
- grener ¤differ kun i liten grad.
+ Og det er vanligvis mer praktisk å bruke denne kommandoen, fordi
+ forskjellene mellom grener ofte er ganske små.
Tjeneren sender bare et minimalt sett med forandringer nødvendig
for å avspeile grenkatalogen.</para>
@@ -3411,7 +3425,7 @@
<quote>trunk</quote> til mesteparten av arbeidskopien deres, men
de ombyttede delene vil forbli immune (unntatt hvis noen legger
inn en forandring til denne grenen).
- Denne funksjonalitetel legger til en hel ny dimensjon til
+ Denne funksjonaliteten legger til en hel ny dimensjon til
konseptet med en <quote>blandet arbeidskopi</quote> – ikke bare
kan arbeidskopier inneholde en blanding av av arbeidsrevisjoner,
men også en blanding av depotbeliggenheter.</para>
@@ -3426,8 +3440,8 @@
<para>Hvis arbeidskopien din inneholder et antall ombyttede
katalogtrær fra forskjellige depotplasseringer, fortsetter den å
virke som normalt.
- Når du oppdaterer, vil du motta patcher til hvert undertre <!-- ¤
- -->der det passer.
+ Når du oppdaterer, vil du motta patcher til hvert undertre der det
+ er nødvendig.
Når du legger inn forandringer, vil dine lokale forandringer
fortsatt bli lagt inn som en enkel, atomisk forandring til
depotet.</para>
@@ -3447,18 +3461,19 @@
</footnote></para>
@ENGLISH }}} -->
<para>Legg merke til at mens det er greit for arbeidskopien din å
- gjenspeile en blanding av depotplasseringer, må alle disse
+ avspeile en blanding av depotplasseringer, må alle disse
plasseringene være innenfor det <emphasis>samme</emphasis>
depotet.
- Subversiondepot er foreløpig ikke i stand til å kommunisere med
+ Subversiondepoter er foreløpig ikke i stand til å kommunisere med
hverandre; det er en funksjonalitet som er planlagt etter
- SUbversion 1.0.<footnote><para>Du <emphasis>kan</emphasis>
- imidlertid bruke <command>svn switch</command> med
- <option>--relocate</option>-valget hvis URL-en til tjeneren
- forandrer seg og du ikke vil forkaste en eksisterende arbeidskopi.
- Se <command>svn switch</command>-seksjonen i <xref
- linkend="svn.ref"/> for mer informasjon og et
- eksempel.</para></footnote></para>
+ Subversion 1.0.<footnote>
+ <para>Du <emphasis>kan</emphasis> imidlertid bruke <command>svn
+ switch</command> med <option>--relocate</option>-valget hvis
+ URL-en til tjeneren forandrer seg og du ikke vil forkaste en
+ eksisterende arbeidskopi.
+ Se <command>svn switch</command>-seksjonen i <xref
+ linkend="svn.ref"/> for mer informasjon og et eksempel.</para>
+ </footnote></para>
<sidebar>
<!-- @ENGLISH {{{
@@ -3475,7 +3490,11 @@
<para>Har du lagt merke til at utdataene fra <command>svn
switch</command> og <command>svn update</command> ser likedan
ut?
- <command>switch</command>-kommandoen er faktisk et ¤superset av
+ <command>switch</command>-kommandoen er faktisk en <!-- ¤
+ «superset»: Overordnet? Utvidet versjon? Eller noe annet? Tror
+ «utvidet versjon» skal gå, i og med at den som sagt lengre nede
+ også flytter kopien gjennom «rom» i tillegg til «tid».
+ -->utvidet versjon av
<command>update</command>-kommandoen.</para>
<!-- @ENGLISH {{{
@@ -3542,7 +3561,7 @@
<command>svn update</command> oppfører den seg på samme måte; alle
lokale modifiseringer i arbeidskopen blir tatt vare på når nye
data ankommer fra depotet.
- Dette lar deg gjøre en masse lure ting.</para>
+ Dette lar deg gjøre alle mulige lure triks.</para>
<!-- @ENGLISH {{{
<para>For example, suppose you have a working copy of
@@ -3553,11 +3572,11 @@
changes will remain. You can then test and commit them to the
branch.</para>
@ENGLISH }}} -->
- <para>For eksempel, tenk at du har en arbeidskopi av
+ <para>For eksempel, tenk deg at du har en arbeidskopi av
<filename>/calc/trunk</filename> og gjør et antall forandringer i
den.
Så finner du plutselig ut at du skulle gjøre disse forandringene
- til en gren istedenfor.
+ på en gren istedenfor.
Ikke noe problem!
Når du bruker <command>svn switch</command> for å flytte
arbeidskopien til grenen, vil de lokale forandringene bli værende.
@@ -3573,7 +3592,8 @@
<!-- @ENGLISH {{{
<title>Tags</title>
@ENGLISH }}} -->
- <title>Merker</title>
+ <title>Merker
+ (<quote><foreignphrase>tags</foreignphrase></quote>)</title>
<!-- @ENGLISH {{{
<para>Another common version control concept is a
@@ -3586,7 +3606,7 @@
<para>Et annet vanlig versjonskontrollkonsept er et
<firstterm>merke</firstterm> – <foreignphrase>tag</foreignphrase>.
Et merke er bare et <quote>øyeblikksbilde</quote> av et prosjekt
- på en spesiell tid.
+ på et spesiell tidspunkt.
I Subversion ser denne idéen ut til å være overalt.
Hver depotrevisjon er akkurat det – et øyeblikksbilde av
filsystemet etter hver innlegging.</para>
@@ -3599,11 +3619,11 @@
piece of software is a particular subdirectory of revision
4822.</para>
@ENGLISH }}} -->
- <para>Men folk vil ofte ønske å gi mer menneskevennlige navn til
- merker, som <literal>release-1.0</literal>.
+ <para>Men folk vil ofte ønske å gi mer menneskevennlige navn på
+ merker, som <literal>versjon-1.0</literal>.
Og de ønsker å ta øyeblikksbilder av mindre underkataloger i
filsystemet.
- Når alt kommer til alt, er det ikke så lett å huske at release-1.0
+ Når alt kommer til alt, er det ikke så lett å huske at versjon-1.0
av et programprosjekt er en spesiell underkatalog av revisjon
4822.</para>
@@ -3628,6 +3648,7 @@
den:</para>
<!-- ¤ -->
+<!-- @ENGLISH {{{
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/tags/release-1.0 \
@@ -3635,6 +3656,14 @@
Committed revision 351.
</screen>
+ at ENGLISH }}} -->
+<screen>
+$ svn copy http://svn.example.com/repos/calc/trunk \
+ http://svn.example.com/repos/calc/tags/versjon-1.0 \
+ -m "Merker 1.0-versjonen av «calc»-prosjektet."
+
+Committed revision 351.
+</screen>
<!-- @ENGLISH {{{
<para>This example assumes that a
@@ -3657,7 +3686,7 @@
(Hvis den ikke gjør det, se <xref
linkend="svn.ref.svn.c.mkdir"/>.)
Etter at kopieringen er fullført, vil den nye
- <filename>release-1.0</filename>-katalogen for alltid være et
+ <filename>versjon-1.0</filename>-katalogen for alltid være et
øyeblikksbilde av hvordan prosjektet så ut i
<literal>HEAD</literal>-revisjonen på den tiden du lagde kopien.
Selvfølgelig vil du være mer presis angående hvilken revisjon du
@@ -3684,15 +3713,15 @@
Er ikke denne prosedyren med opprettelse av merker den samme
prosedyren som vi brukte da vi lagde en gren?
Ja, faktisk er det det.
- I Subversion er det ingen forskjell mellom et merke og en gren.
+ I Subversion er det ingen forskjell på et merke og en gren.
Begge er bare vanlige kataloger som er opprettet ved kopiering.
- Akkurat som med grener, den eneste grunnen til at en kopiert
- katalog er et <quote>merke</quote> er fordi
+ Akkurat som med grener er den eneste grunnen til at en kopiert
+ katalog er et <quote>merke</quote> fordi
<emphasis>mennesker</emphasis> har bestemt seg for å behandle
- det på denne måten:
- Så lenge ingen noen gang legger inn forandringer til katalogen,
- forblir den for alltid et øyeblikksbilde.
- Hvis noen begynner å legge inn forandringer til den, blir den en
+ den på denne måten:
+ Så lenge ingen legger inn forandringer i katalogen, forblir den
+ for alltid et øyeblikksbilde.
+ Hvis noen begynner å legge inn forandringer i den, blir den en
gren.</para>
<!-- @ENGLISH {{{
@@ -3714,7 +3743,7 @@
<para>Hvis du administrerer et depot, er det to fremgangsmåter du
kan bruke for å holde rede på merker.
Den første fremgangsmåten er <quote>ikke rør</quote>:
- Som en del av reglene innen prosjektet, bestem hvor i depotet
+ Som en del av reglene for prosjektet, bestem hvor i depotet
merkene skal ligge, og gjør det klart for alle brukere hvordan
de skal behandle kataloger som de kopierer inn dit.
(Det vil si, vær sikker på at de vet at nye innlegginger ikke
@@ -3725,7 +3754,7 @@
opprette nye kopier i merkeområdet (se <xref
linkend="svn.serverconfig"/>).
Den paranoide ruten er imidlertid vanligvis ikke nødvendig.
- Hvis en bruker legger inn en forandring til en merkekatalog, kan
+ Hvis en bruker legger inn en forandring i en merkekatalog, kan
du enkelt og greit omgjøre forandringen som nevnt i den forrige
seksjonen.
Dette er versjonskontroll, tross alt.</para>
@@ -3767,11 +3796,11 @@
<filename>calc</filename>-eksempelet vårt:
Det inneholder mange underkataloger og mange flere filer.
Mens du holder på med arbeidet, bestemmer du deg kanskje for at
- du må lage en arbeidskopi som er beregnet på å ha en spesiell
- funksjonalitet og feilrettinger.
+ du må lage en arbeidskopi som skal ha en spesiell funksjonalitet
+ sammen med feilrettinger.
Du kan oppnå dette ved å selektivt tilbakedatere filer eller
kataloger til spesielle revisjoner (ved å bruke <command>svn
- update -r</command> i stor skala), eller ved å bytte om filer og
+ update -r</command> i stor skala) eller ved å bytte om filer og
kataloger til spesielle grener (ved hjelp av <command>svn
switch</command>).
Når du er ferdig, er arbeidskopien din et virvar av
@@ -3798,6 +3827,7 @@
depotet:</para>
<!-- ¤ -->
+<!-- @ENGLISH {{{
<screen>
$ ls
my-working-copy/
@@ -3806,6 +3836,16 @@
Committed revision 352.
</screen>
+ at ENGLISH }}} -->
+<screen>
+$ ls
+min-arbeidskopi/
+
+$ svn copy min-arbeidskopi
+http://svn.example.com/repos/calc/tags/mittmerke
+
+Committed revision 352.
+</screen>
<!-- @ENGLISH {{{
<para>Now there is a new directory in the repository,
@@ -3814,7 +3854,7 @@
and all.</para>
@ENGLISH }}} -->
<para>Nå er det en ny katalog i depotet,
- <filename>/calc/tags/mytag</filename>, som er et eksakt
+ <filename>/calc/tags/mittmerke</filename>, som er et eksakt
øyeblikksbilde av arbeidskopien din – blandede revisjoner, URLer
og hele pakken.</para>
@@ -3871,7 +3911,7 @@
mekanismen (kopier av kataloger), og fordi grener og merker vises
i filsystemet, finner mange Subversion <!-- ¤ -->litt skremmende.
Den er nesten <emphasis>for</emphasis> fleksibel.
- I denne seksjonen vil vi komme med noen forslag for hvordan du kan
+ I denne seksjonen vil vi komme med noen forslag på hvordan du kan
arrangere og vedlikeholde dataene dine over tid.</para>
<!-- =============================================================== -->
@@ -3879,7 +3919,7 @@
<!-- @ENGLISH {{{
<title>Repository Layout</title>
@ENGLISH }}} -->
- <title><!-- ¤ -->Layout på depotet</title>
+ <title>Utseendet på depotet</title>
<!-- @ENGLISH {{{
<para>There are some standard, recommended ways to organize a
@@ -3892,8 +3932,8 @@
@ENGLISH }}} -->
<para>Det er noen standardiserte, anbefalte måter å organisere et
depot på.
- Mange lager en <filename>trunk</filename>-katalog for der
- <quote>hovedlinjen</quote> av utvikling foregår, en
+ Mange lager en <filename>trunk</filename>-katalog for å lagre
+ <quote>hovedlinjen</quote> av utviklingen, en
<filename>branches</filename>-katalog som inneholder grenkopier,
og en <filename>tags</filename>-katalog som inneholder merker.
Hvis et depot bare inneholder ett prosjekt, lager man ofte disse
@@ -3937,8 +3977,8 @@
you don't like the way things are organized in the repository,
just juggle the directories around.</para>
@ENGLISH }}} -->
- <para>Du står selvfølgelig fritt til å ignorere disse vanlige <!--
- ¤ -->layoutene.
+ <para>Du står selvfølgelig fritt til å ignorere disse vanlige
+ oppsettene.
Du kan lage alle mulige varianter, hva som enn fungerer best for
deg og ditt team.
Husk at hva du enn velger, er du ikke forpliktet til å ha det
@@ -3947,10 +3987,10 @@
Fordi grener og merker er vanlige kataloger, kan <command>svn
move</command>-kommandoen flytte eller skifte navn på dem sånn
som du ønsker.
- Å bytte fra en layout til en annen er bare snakk om å <!--
- utføre --> en serie flyttinger på tjeneren; hvis du ikke liker
- måten ting er organisert i depotet, bare <!-- ¤ -->flytt
- katalogene rundt om kring.</para>
+ Å bytte fra et utseende til et annet er bare snakk om å utføre
+ en serie flyttinger på tjeneren; hvis du ikke liker måten ting
+ er organisert på i depotet, er det bare å ommøblere på
+ katalogene.</para>
<!-- @ENGLISH {{{
<para>Remember, though, that while moving directories may be
@@ -4000,19 +4040,28 @@
<para>En annen fin funksjonalitet med Subversions modell er at
grener og merker kan ha begrenset levetid, akkurat som ethvert
annet versjonert element.
- For eksempel, tenk at du etterhvert blir ferdig med alt arbeidet
- på din personlige gren i <filename>calc</filename>-prosjektet.
+ Tenk deg for eksempel at du etterhvert blir ferdig med alt
+ arbeidet på din personlige gren i
+ <filename>calc</filename>-prosjektet.
Etter at du har flettet alle dine forandringer tilbake til
<filename>/calc/trunk</filename>, trenger ikke grenkatalogen å
ligge der mer:</para>
<!-- ¤ -->
+<!-- @ENGLISH {{{
<screen>
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Removing obsolete branch of calc project."
Committed revision 375.
</screen>
+ at ENGLISH }}} -->
+<screen>
+$ svn delete http://svn.example.com/repos/calc/branches/min-calc-gren \
+ -m "Fjerner avlegs gren i calc-prosjektet."
+
+Committed revision 375.
+</screen>
<!-- @ENGLISH {{{
<para>And now your branch is gone. Of course it's not really
@@ -4048,12 +4097,20 @@
copy -r</command> for å kopiere den fra den gamle
revisjonen:</para>
+<!-- @ENGLISH {{{
<screen>
$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
http://svn.example.com/repos/calc/branches/my-calc-branch
Committed revision 376.
</screen>
+ at ENGLISH }}} -->
+<screen>
+$ svn copy -r 374 http://svn.example.com/repos/calc/branches/min-calc-gren \
+ http://svn.example.com/repos/calc/branches/min-calc-gren
+
+Committed revision 376.
+</screen>
<!-- @ENGLISH {{{
<para>In our example, your personal branch had a relatively
@@ -4077,10 +4134,10 @@
Men innen programutvikling er det også vanlig å ha to
<quote>hoved</quote>-grener som lever ved siden av hverandre for
veldig lange perioder.
- For eksempel, tenk at det er på tide å utgi en stabil versjon av
- <filename>calc</filename>-prosjektet til offentligheten, og du
- vet at det kommer til å ta noen måneder å luke ut feil av
- programmet.
+ For eksempel, tenk deg at det er på tide å utgi en stabil
+ versjon av <filename>calc</filename>-prosjektet til
+ offentligheten, og du vet at det kommer til å ta noen måneder å
+ luke ut feil av programmet.
Du vil ikke at folk skal legge inn ny funksjonalitet til
prosjektet, men du vil heller ikke at utviklerne skal stoppe
programmeringen.
@@ -4088,6 +4145,7 @@
programmet som ikke vil forandre seg så mye:</para>
<!-- ¤ -->
+<!-- @ENGLISH {{{
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/stable-1.0 \
@@ -4095,6 +4153,14 @@
Committed revision 377.
</screen>
+ at ENGLISH }}} -->
+<screen>
+$ svn copy http://svn.example.com/repos/calc/trunk \
+ http://svn.example.com/repos/calc/branches/stabil-1.0 \
+ -m "Lager stabil gren av calc-prosjektet."
+
+Committed revision 377.
+</screen>
<!-- @ENGLISH {{{
<para>And now developers are free to continue adding
@@ -4111,8 +4177,8 @@
<para>Og nå kan utviklerne fortsette med å legge til rykende
ferske (eller eksperimentelle) funksjoner til
<filename>/calc/trunk</filename>, og du kan lage en regel for
- prosjektet som sier at bare feilrettinger skal legges inn i
- <filename>/calc/branches/stable-1.0</filename>.
+ prosjektet som sier at kun feilrettinger skal legges inn i
+ <filename>/calc/branches/stabil-1.0</filename>.
Det vil si, mens brukerne fortsetter å arbeide i trunk, kan
feilrettinger selektivt bli flettet over til den stabile grenen.
Selv etter at den stabile grenen er på markedet, vil du
@@ -4146,8 +4212,8 @@
might manage the organization and lifetimes of branches in a
repository.</para>
@ENGLISH }}} -->
- <para>Vi har gått igjennom en god del i dette kapittelet.
- Vi har diskutert konseptene med merker og grener, og demonstrert
+ <para>Vi har gått gjennom en god del i dette kapittelet.
+ Vi har diskutert konseptene rundt merker og grener, og demonstrert
hvordan Subversion implementerer disse konseptene ved å kopiere
kataloger med <command>svn copy</command>-kommandoen.
Vi har vist hvordan <command>svn merge</command> brukes for å
@@ -4164,7 +4230,7 @@
@ENGLISH }}} -->
<para>Husk mantraet til Subversion:
Grener og merker er billige.
- Så bruk dem så mye du vil!</para>
+ Bruk dem så mye du vil!</para>
</sect1>
More information about the svnbook-dev
mailing list