[svnbook commit] r2764 - in trunk/src/nb: . book
sunny256
noreply at red-bean.com
Wed Mar 28 12:56:52 CDT 2007
Author: sunny256
Date: Wed Mar 28 12:56:51 2007
New Revision: 2764
Log:
* src/nb/book/ch-branching-and-merging.xml
(svn.advanced.vendorbr): Translated some paragraphs.
* src/nb/TRANSLATION-STATUS
(Needs update): Removed tranlation percent.
Modified:
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch-branching-and-merging.xml
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Wed Mar 28 12:56:51 2007
@@ -38,8 +38,8 @@
2.1.3. Needs update
- book/ch-branching-and-merging.xml (84%) -- Untranslated section
- after r2572 was merged.
+ book/ch-branching-and-merging.xml -- Untranslated section after
+ r2572 was merged.
2.1.4. Untranslated
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 Wed Mar 28 12:56:51 2007
@@ -4369,8 +4369,12 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<sect1 id="svn.advanced.vendorbr">
+ <!-- @ENGLISH {{{
<title>Vendor branches</title>
+ @ENGLISH }}} -->
+ <title>Leverandørgrener</title>
+ <!-- @ENGLISH {{{
<para>As is especially the case when developing software, the data
that you maintain under version control is often closely related
to, or perhaps dependent upon, someone else's data. Generally,
@@ -4380,7 +4384,19 @@
This scenario plays itself out all the time—anywhere that
the information generated by one group of people has a direct
effect on that which is generated by another group.</para>
+ @ENGLISH }}} -->
+ <para>Som det ofte er når man utvikler programvare, er dataene du
+ har under versjonskontroll ofte nært knyttet til, eller avhengig
+ av, noen andres data.
+ Vanligvis vil behovene til prosjektet ditt tilsi at du holder deg
+ mest mulig oppdatert som mulig med dataene som du får fra denne
+ eksterne enheten uten å ofre stabiliteten til ditt eget
+ prosjekt.
+ Denne situasjonen oppstår hele tiden – alle steder der
+ informasjonen generert av en gruppe har en direkte effekt på hva
+ som er generert av en annen gruppe.</para>
+ <!-- @ENGLISH {{{
<para>For example, software developers might be working on an
application which makes use of a third-party library.
Subversion has just such a relationship with the Apache Portable
@@ -4392,7 +4408,22 @@
library's code churn. Now that both APR and Subversion have
matured, Subversion attempts to synchronize with APR's library
API only at well-tested, stable release points.</para>
+ @ENGLISH }}} -->
+ <para>For eksempel, programvareutviklere kan utvikle en programpakke
+ som bruker tredjeparts biblioteker.
+ Subversion har akkurat et slikt forhold til <foreignphrase
+ lang="en">Apache Portable Runtime library</foreignphrase> (se
+ <xref linkend="svn.developer.usingapi.apr" />).
+ Kildekoden til Subversion avhenger av APR-biblioteket for alle
+ behov innen portabilitet.
+ I tidligere faser av utviklingen til Subversion, fulgte prosjektet
+ brukergrensesittet for APR veldig nøye, og brukte alltid den helt
+ nyeste koden til biblioteket.
+ Så som både APR og Subversion har modnet, prøver Subversion å
+ synkronisere med kun velprøvde, stabile utgaver av
+ APR-biblioteket.<quote></quote></para>
+ <!-- @ENGLISH {{{
<para>Now, if your project depends on someone else's information,
there are several ways that you could attempt to synchronize that
information with your own. Most painfully, you could issue oral
@@ -4404,7 +4435,21 @@
definitions to effectively <quote>pin down</quote> specific
versions of that information to some location in your own
working copy directory (see <xref linkend="svn.advanced.externals" />).</para>
+ @ENGLISH }}} -->
+ <para>Hvis prosjektet ditt nå består av noen adres informasjon, er
+ det flere måter du kan prøve å synkronisere denne informasjonen
+ med din egen.
+ Det mest smertefulle kan være å gi muntlige eller nedskrevne
+ instruksjoner til alle bidragsyterne for prosjektet, og fortelle
+ dem at de må være sikre på at de har de absolutt riktige
+ versjonene av denne tredjepartsinformasjonen.
+ Hvis tredjepartsinformasjonen lagres i et Subversion-depot, kan du
+ også bruke Subversions externals-definisjon for å effektivt
+ <quote>nagle fast</quote> spesifikke versjoner av den
+ informasjonen til en spesiell plassering i din egen arbeidskopi
+ (se <xref linkend="svn.advanced.externals" />).</para>
+ <!-- @ENGLISH {{{
<para>But sometimes you want to maintain custom modifications to
third-party data in your own version control system. Returning
to the software development example, programmers might need to
@@ -4415,7 +4460,22 @@
changes might never be relayed back to the library maintainers,
existing solely as custom tweaks to make the library further
suit the needs of the software developers.</para>
+ @ENGLISH }}} -->
+ <para>Men noen ganger vil du vedlikeholde spesialtilpassede
+ versjoner av tredjeparts programvare i ditt eget
+ versjonskontrollsystem.
+ Hvis vi går tilbake til programutviklingseksempelet, kan det være
+ nødvendig for programmerere å gjøre forandringer i
+ tredjepartsbiblioteket for eget bruk.
+ Disse forandringene kan inneholde ny funksjonalitet eller
+ filrettinger, internt vedlikeholdt bare til de blir del av en
+ offisiell utgivelse av tredjepartsbiblioteket.
+ Eller forandringene blir kanskje aldri sendt tilbake til
+ vedlikeholderne av biblioteket, men fungerer bare som
+ hjemmeskrudde løsninger for å få biblioteket til å dekke behovene
+ enda bedre.</para>
+ <!-- @ENGLISH {{{
<para>Now you face an interesting situation. Your project could
house its custom modifications to the third-party data in some
disjointed fashion, such as using patch files or full-fledged
@@ -4424,14 +4484,37 @@
to apply your custom changes to the third-party data, and
necessitating regeneration of those changes with each successive
version of the third-party data that you track.</para>
+ @ENGLISH }}} -->
+ <para>Nå står du ovenfor en interessant situasjon.
+ Prosjektet ditt kunne lagret spesialforandringene i
+ tredjepartsdataene som noe helt annet, som å bruke patchfiler
+ eller fullstendige alternative versjoner av filer og kataloger.
+ Men dette vedlikeholdet har en tendens til å bli en hodepine som
+ krever en eller annen mekanisme som du bruker til å legge inn dine
+ spesialforandringer i tredjepartsdataene.
+ Det vil også være nødvendig å regenerere disse forandringene med
+ hver eneste etterfølgende versjon av tredjepartsdataene som du
+ følger med på.</para>
+ <!-- @ENGLISH {{{
<para>The solution to this problem is to use <firstterm>vendor
branches</firstterm>. A vendor branch is a directory tree in
your own version control system that contains information
provided by a third-party entity, or vendor. Each version of
the vendor's data that you decide to absorb into your project is
called a <firstterm>vendor drop</firstterm>.</para>
+ @ENGLISH }}} -->
+ <para>Løsningen på dette problemet er å bruke
+ <firstterm>leverandørgrener</firstterm> (engelsk: <foreignphrase
+ lang="en">vendor branches</foreignphrase>).
+ En leverandørgren er et katalogtre i deitt eget
+ versjonskontrollsystem som inneholder informasjon utgitt av en
+ tredjepart eller leverandør.
+ Hver versjon av leverandørens data som du bestemmer det for å
+ legge inn i prosjektet ditt, kalles <!-- ¤¤¤ --><firstterm>vendor
+ drop</firstterm>.</para>
+ <!-- @ENGLISH {{{
<para>Vendor branches provide two key benefits. First, by storing
the currently supported vendor drop in your own version control
system, the members of your project never need to question
@@ -4441,6 +4524,16 @@
own Subversion repository, you can store your custom changes to
it in-place—you have no more need of an automated (or
worse, manual) method for swapping in your customizations.</para>
+ @ENGLISH }}} -->
+ <para>Leverandørgrener gir to fordeler.
+ For det første, ved å lagre <!-- ¤ -->den nåværende versjonen av
+ leverandørdataene i ditt eget versjonskontrollsystem, trenger
+ medlemmene i prosjektet ditt aldri å lure på om de har den riktige
+ versjonen som en del av de vanlige arbeidskopioppdateringene.
+ For det andre, fordi dataene er i ditt eget Subversiondepot, kan
+ du lagre forandringene dine direkte i dem – du trenger ikke lengre
+ å ha en automatisert (eller enda verre, manuell) metode for å
+ legge inn tilpasningene dine.</para>
<!-- =============================================================== -->
<sect2 id="svn.advanced.vendorbr.general">
More information about the svnbook-dev
mailing list