[svnbook commit] r2769 - trunk/src/nb/book
sunny256
noreply at red-bean.com
Fri Mar 30 16:08:12 CDT 2007
Author: sunny256
Date: Fri Mar 30 16:08:12 2007
New Revision: 2769
Log:
* src/nb/book/ch-branching-and-merging.xml
(svn.advanced.vendorbr.general): Translated.
Modified:
trunk/src/nb/book/ch-branching-and-merging.xml
Modified: trunk/src/nb/book/ch-branching-and-merging.xml
==============================================================================
--- trunk/src/nb/book/ch-branching-and-merging.xml (original)
+++ trunk/src/nb/book/ch-branching-and-merging.xml Fri Mar 30 16:08:12 2007
@@ -4537,8 +4537,13 @@
<!-- =============================================================== -->
<sect2 id="svn.advanced.vendorbr.general">
+ <!-- @ENGLISH {{{
<title>General Vendor Branch Management Procedure</title>
+ @ENGLISH }}} -->
+ <title>Generell prosedyre for vedlikehold av
+ leverandørgrener</title>
+ <!-- @ENGLISH {{{
<para>Managing vendor branches generally works like this. You
create a top-level directory (such as
<filename>/vendor</filename>) to hold the vendor branches.
@@ -4552,7 +4557,25 @@
<filename>/trunk</filename>, resolving whatever conflicts
occur between your local changes and the upstream
changes.</para>
+ @ENGLISH }}} -->
+ <para>Dette er måten vedlikehold av leverandørgrener vanligvis
+ fungerer på.
+ Du lager en katalog på toppnivå (som for eksempel
+ <filename>/vendor</filename>) for å lagre leverandørgrenene.
+ Deretter importerer du tredjepartskoden inn i en underkatalog i
+ denne toppkatalogen.
+ Så kopierer du denne underkatalogen inn på grenen der
+ hovedutviklingen foregår (for eksempel
+ <filename>/trunk</filename> på den riktige plasseringen.
+ Du gjør alltid dine lokale forandringer på grenen der
+ hovedutviklingen foregår.
+ For hver ny utgivelse av koden du følger med på, legger du den
+ inn på leverandørgrenen og fletter forandringene inn i
+ <filename>/trunk</filename> og ordner eventuelle konflikter som
+ måtte oppstå mellom dine lokale forandringer og de offisielle
+ forandringene.</para>
+ <!-- @ENGLISH {{{
<para>Perhaps an example will help to clarify this algorithm.
We'll use a scenario where your development team is creating a
calculator program that links against a third-party complex
@@ -4565,14 +4588,38 @@
import</command> creates all the intermediate parent
directories it needs, we can actually accomplish both of these
steps with a single command.</para>
+ @ENGLISH }}} -->
+ <para>Kanskje vil et eksempel hjelpe på å klarne opp i
+ fremgangsmåten.
+ Vi bruker en situasjon der utviklingsteamet lager et
+ regneprogram som lenker mot et tredjeparts bibliotek for
+ kompleks aritmetikk, libcomplex.
+ Vi starter med den innledende opprettelsen av <!-- ¤
+ -->leverandørgrenen og den første importen av
+ leverandørutgivelsen.
+ Vi kaller leverandørgrenen <filename>libcomplex</filename>, og
+ <!-- ¤ -->leverandørutgivelsene går i en underkatalog i
+ leverandørgrenen kalt <filename>current</filename>.
+ Og siden <command>svn import</command> oppretter alle de
+ mellomliggende foreldrekataloger som vi trenger, kan vi faktisk
+ gjøre begge disse stegene med en enkelt kommando.</para>
+ <!-- @ENGLISH {{{
<screen>
$ svn import /path/to/libcomplex-1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
-m 'importing initial 1.0 vendor drop'
…
</screen>
+ @ENGLISH }}} -->
+ <screen>
+$ svn import /sti/til/libcomplex-1.0 \
+ http://svn.example.com/repos/vendor/libcomplex/current \
+ -m 'Importerer innledende 1.0-versjon'
+…
+</screen>
+ <!-- @ENGLISH {{{
<para>We now have the current version of the libcomplex source
code in <filename>/vendor/libcomplex/current</filename>. Now,
we tag that version (see <xref linkend="svn.branchmerge.tags" />)
@@ -4582,7 +4629,19 @@
<filename>calc</filename> project directory. It is in this
copied version of the vendor data that we will make our
customizations.</para>
+ @ENGLISH }}} -->
+ <para>Vi har nå den nåværende versjonen av libcomplex-kildekoden i
+ <filename>/vendor/libcomplex/current</filename>.
+ Nå merker vi denne versjonen (se <xref
+ linkend="svn.branchmerge.tags" /> og deretter kopierer den inn
+ på hovedutviklingsgrenen.
+ Kopien vår vil opprette en ny katalog kalt
+ <filename>libcomplex</filename> i den eksisterende
+ prosjektkatalogen <filename>calc</filename>.
+ Det er i denne kopien av leverandørdataene vi vil gjøre
+ forandringene.</para>
+ <!-- @ENGLISH {{{
<screen>
$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
@@ -4593,7 +4652,19 @@
-m 'bringing libcomplex-1.0 into the main branch'
…
</screen>
+ @ENGLISH }}} -->
+ <screen>
+$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \
+ http://svn.example.com/repos/vendor/libcomplex/1.0 \
+ -m 'Merker libcomplex-1.0'
+…
+$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \
+ http://svn.example.com/repos/calc/libcomplex \
+ -m 'Legger libcomplex-1.0 inn på hovedgrenen'
+…
+</screen>
+ <!-- @ENGLISH {{{
<para>We check out our project's main branch—which now
includes a copy of the first vendor drop—and we get to
work customizing the libcomplex code. Before we know it, our
@@ -4603,7 +4674,17 @@
<para>And entirely bug-free, of course!</para>
</footnote>
</para>
+ @ENGLISH }}} -->
+ <para>Vi henter ut prosjektets hovedgren – som nå inneholder en
+ kopi av den første <!-- ¤ -->leverandørutgivelsen – og vi setter
+ i gang med å tilpasse libcomplex-koden.
+ Før vi vet ordet av det, er den modifiserte versjonen av
+ libcomplex fullstendig integrert i
+ kalkulatorprogrammet.<footnote>
+ <para>Og uten en eneste bug, selvfølgelig!</para>
+ </footnote></para>
+ <!-- @ENGLISH {{{
<para>A few weeks later, the developers of libcomplex release a
new version of their library—version 1.1—which
contains some features and functionality that we really want.
@@ -4616,7 +4697,20 @@
approach the problem from the other direction, applying the
changes made to libcomplex between versions 1.0 and 1.1 to our
modified copy of it.</para>
+ @ENGLISH }}} -->
+ <para>Noen uker senere slipper utviklerne av libcomplex en ny
+ versjon av biblioteket – versjon 1.1 – som inneholder trivelig
+ funksjonalitet som vi har lyst på.
+ Vi vil oppgradere til denne nye versjonen, men uten å miste
+ forandringene vi gjorde i den eksisterende versjonen.
+ Det vi egentlig vil gjøre, er å erstatte den nåværende
+ utviklingsversjonen med en kopi av libcomplex 1.1 og deretter
+ legge inn forandringene våre i den nye versjonen.
+ Men vi gjør det faktisk den andre veien, legger inn
+ forandringene i libcomplex mellom versjon 1.0 og 1.1 i den
+ modifiserte kopien av den.</para>
+ <!-- @ENGLISH {{{
<para>To perform this upgrade, we checkout a copy of our vendor
branch, and replace the code in the
<filename>current</filename> directory with the new libcomplex
@@ -4628,7 +4722,22 @@
that code is under version control. Oh, and we want to do
this with as little version control history disturbance as
possible.</para>
+ @ENGLISH }}} -->
+ <para>For å gjennomføre denne oppgraderingen, henter vi ut en kopi
+ av leverandørgrenen og erstatter koden i
+ <filename>current</filename>-katalogen med den nye koden for
+ libcomplex 1.1.
+ Vi kopierer bokstavelig talt nye filer på toppen av eksisterende
+ filer, kanskje ved å pakke ut <filename>.tar.gz</filename>-fila
+ oppå de eksisterende filene og katalogene.
+ Meningen med dette er å få
+ <filename>current</filename>-katalogen til å inneholde kun koden
+ fra libcomplex 1.1, og å forsikre seg om at all denne koden er
+ under versjonskontroll.
+ Og en annen ting var at vi ville at dette skulle skje uten å
+ forstyrre versjonskontrollhistorien alt for mye.</para>
+ <!-- @ENGLISH {{{
<para>After replacing the 1.0 code with 1.1 code, <command>svn
status</command> will show files with local modifications as
well as, perhaps, some unversioned or missing files. If we
@@ -4641,14 +4750,37 @@
<filename>current</filename> working copy contains only the
libcomplex 1.1 code, we commit the changes we made to get it
looking that way.</para>
+ @ENGLISH }}} -->
+ <para>Etter å ha erstattet 1.0-koden med 1.1, vil <command>svn
+ status</command> vise filer med lokale forandringer sammen med
+ filer som kanskje er uversjonert eller mangler.
+ Hvis vi gjorde det vi skulle, er de uversjonerte filene bare de
+ nye filene introdusert i 1.1-versjonen av libcomplex – vi kjører
+ <command>svn add</command> på disse for å få dem under
+ versjonskontroll.
+ De manglende filene er filer som var i 1.0, men ikke i 1.1, og
+ på disse stiene kjører vi <command>svn delete</command>.
+ Helt til slutt, når <filename>current</filename>-arbeidskopien
+ kun inneholder koden for libcomplex 1.1, legger vi inn
+ forandringene vi gjorde for å få den til å se ut som den
+ gjør.</para>
+ <!-- @ENGLISH {{{
<para>Our <filename>current</filename> branch now contains the
new vendor drop. We tag the new version (in the same way we
previously tagged the version 1.0 vendor drop), and then merge
the differences between the tag of the previous version and
the new current version into our main development
branch.</para>
+ @ENGLISH }}} -->
+ <para>Nå inneholder <filename>current</filename>-grenen den nye
+ leverandørversjonen.
+ Vi merker den nye versjonen (på den samme måten vi tidligere
+ merket 1.0-versjonen) og fletter deretter forandringene mellom
+ merket for den forrige versjonen og den nye gjeldende versjonen
+ inn i hovedutviklingsgrenen.</para>
+ <!-- @ENGLISH {{{
<screen>
$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \
@@ -4658,7 +4790,18 @@
$ svn commit -m 'merging libcomplex-1.1 into the main branch'
…
</screen>
+ @ENGLISH }}} -->
+ <screen>
+$ cd arbeidskopier/calc
+$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \
+ http://svn.example.com/repos/vendor/libcomplex/current \
+ libcomplex
+… # Rydd opp i alle konfliktene mellom deres og våre forandringer
+$ svn commit -m 'merging libcomplex-1.1 into the main branch'
+…
+</screen>
+ <!-- @ENGLISH {{{
<para>In the trivial use case, the new version of our
third-party tool would look, from a files-and-directories
point of view, just like the previous version. None of the
@@ -4668,7 +4811,19 @@
In a perfect world, our modifications would apply cleanly to
the new version of the library, with absolutely no
complications or conflicts.</para>
+ @ENGLISH }}} -->
+ <para>I enkle sitasjoner vil den nye versjonen av
+ tredjepartsdataene se ut som, fra et fil og katalog-syn, akkurat
+ om den forrige versjonen.
+ Ingen av filene i libcomplex vil være slettet, ha fått nytt navn
+ eller blitt flyttet til andre plasseringer – den nye versionen
+ vil bare inneholde tekstmessige forandringer i forhold til den
+ forrige.
+ I en perfekt verden ville våre forandringer legge seg inn i den
+ nye versjonen uten antydning til komplikasjoner eller
+ konflikter.</para>
+ <!-- @ENGLISH {{{
<para>But things aren't always that simple, and in fact it is
quite common for source files to get moved around between
releases of software. This complicates the process of
@@ -4681,6 +4836,20 @@
the library is pretty simple. But we are responsible for
telling Subversion how the source file layout changed from
vendor drop to vendor drop.</para>
+ @ENGLISH }}} -->
+ <para>Men det er ikke alltid så enkelt, og faktisk er det ganske
+ vanlig for kildekodefiler å bli flyttet rundt mellom
+ programutgivelser.
+ Dette kompliserer prosessen som går ut på å forsikre seg om at
+ våre forandringer fortsatt er gyldige for den nye versjonen av
+ koden, noe som kan ende med den situasjonen at vi manuelt må
+ gjenopprette våre forandringer i den nye versjonen.
+ Når Subversion vet om historien til en gitt kildefil – inkludert
+ alle dens tidligere plasseringer – er prosessen med å flette inn
+ den nye versjonen av biblioteket ganske enkel.
+ Men vi er ansvarlig for å fortelle Subversion hvordan
+ kildekodelayouten forandret seg fra leverandørversjon til
+ leverandørversjon.</para>
</sect2>
More information about the svnbook-dev
mailing list