[svnbook commit] r1174 - in trunk/src/nb: . book
sunny256 at red-bean.com
sunny256 at red-bean.com
Tue Mar 15 21:18:11 CST 2005
Author: sunny256
Date: Tue Mar 15 21:18:10 2005
New Revision: 1174
Modified:
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch05.xml
Log:
Norwegian svnbook: Finished "Repository Maintenance" section in ch05.xml .
* src/nb/TRANSLATION-STATUS
ch05.xml to 93%.
* src/nb/book/ch05.xml
Finished "Repository Maintenance" section.
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Tue Mar 15 21:18:10 2005
@@ -34,7 +34,7 @@
2.1.2. In progress
- book/ch05.xml (89%) -- sunny256
+ book/ch05.xml (93%) -- sunny256
2.1.3. Needs update
Modified: trunk/src/nb/book/ch05.xml
==============================================================================
--- trunk/src/nb/book/ch05.xml (original)
+++ trunk/src/nb/book/ch05.xml Tue Mar 15 21:18:10 2005
@@ -4974,6 +4974,7 @@
deretter rense bort de døde Berkeleyloggfilene fra det aktive
depotet.</para>
+ <!-- @ENGLISH {{{
<para>Even if you also have an incremental backup, you might
want to run this program on a regular basis. For example, you
might consider adding <command>hot-backup.py</command> to a
@@ -4986,15 +4987,42 @@
created. Simply add the following to the
<filename>hooks/post-commit</filename> script in your live
repository directory:</para>
+ @ENGLISH }}} -->
+ <para>Selv om du også har en inkrementell backup, vil du
+ sannsynligvis ville kjøre dette programmet på en <!-- ¤ Vi
+ bruker å si det, ikke sant? -->regulær basis.
+ For eksempel vil du kanskje vurdere å legge til
+ <command>hot-backup.py</command> til en automatisk
+ programkjøring (som <command>cron</command> på Unix-systemer).
+ Eller, hvis du foretrekker finkornede backupløsninger, kan du
+ sette post-commit-skriptet til å kalle
+ <command>hot-backup.py</command> (se <xref
+ linkend="svn-ch-5-sect-2.1" />), som vil lage en ny kopi av
+ depotet for hver ny revisjon som er opprettet.
+ Bare legg til det følgende til
+ <filename>hook/post-commit</filename>-skriptet i katalogen til
+ det aktive depotet:</para>
+ <!-- @ENGLISH {{{
<programlisting>
(cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &)
</programlisting>
+ @ENGLISH }}} -->
+ <programlisting>
+(cd /sti/til/påhakningsskript; \
+ ./hot-backup.py ${REPOS} /sti/til/sikkerhetskopier &)
+</programlisting>
+ <!-- @ENGLISH {{{
<para>The resulting backup is a fully functional Subversion
repository, able to be dropped in as a replacement for your
live repository should something go horribly wrong.</para>
+ @ENGLISH }}} -->
+ <para>Den resulterende backupen er et fullstendig fungerende
+ Subversiondepot som du kan legge inn som en erstatning for det
+ aktive depotet i tilfelle noe skulle gå forferdelig galt.</para>
+ <!-- @ENGLISH {{{
<para>There are benefits to both types of backup methods. The
easiest is by far the full backup, which will always result in
a perfect working replica of your repository. This again
@@ -5004,7 +5032,19 @@
maintaining multiple backups of your repository, these full
copies will each eat up just as much disk space as your live
repository.</para>
+ @ENGLISH }}} -->
+ <para>Det er fordeler med begge backupmetodene.
+ Den letteste er helt klart å ta en full sikkerhetskopi, som
+ alltid vil resultere i en fullstendig funksjonell duplikat av
+ depotet ditt.
+ Dette betyr igjen at hvis noe stygt skulle skje med det aktive
+ depotet, kan du hente det tilbake fra sikkerhetskopien med en
+ enkel rekursiv katalogkopiering.
+ Uheldigvis, hvis du har flere kopier av depotet, vil disse
+ fullstendige kopiene spise opp like mye diskplass som det aktive
+ depotet.</para>
+ <!-- @ENGLISH {{{
<para>Incremental backups using the repository dump format are
excellent to have on hand if the database schema changes
between successive versions of Subversion itself. Since a
@@ -5015,7 +5055,19 @@
restoration from—incremental backups takes longer, as
each commit is effectively replayed into either the dump file
or the repository.</para>
+ @ENGLISH }}} -->
+ <para>Inkrementelle backuper som bruker depotdumpformatet er
+ utmerket å ha for hånden hvis oppbygningen av databasen
+ forandrer seg mellom versjonene av selve Subversion.
+ Siden en komplett depotdump og depotlasting vanligvis er
+ nødvendig for å oppgradere depotet ditt til det nye formatet, er
+ det veldig enkelt å allerede ha halvparten av denne prosessen
+ (dumpdelen) overstått.
+ Uheldigvis tar opprettelsen av — og gjenoppretting fra —
+ inkrementelle bakuper lengre tid, fordi hver innlegging enten
+ blir spilt av inn i dumpfilen eller depotet.</para>
+ <!-- @ENGLISH {{{
<para>In either backup scenario, repository administrators need
to be aware of how modifications to unversioned revision
properties affect their backups. Since these changes do not
@@ -5032,7 +5084,24 @@
latest few revisions might not catch a property modification
to a revision that was included as part of a previous
backup.</para>
+ @ENGLISH }}} -->
+ <para>I begge disse backupscenariene må depotadminstratorer være
+ oppmerksom på hvordan forandringer i uversjonerte
+ revisjonsegenskaper påvirker sikkerhetskopiene.
+ Siden disse forandringene ikke selv lager nye revisjoner, vil de
+ ikke aktivisere post-commit-påhakninger, og kanskje heller ikke
+ aktivisere pre-revprop-change- og
+ post-revprop-change-skriptene.<footnote><para><command>svnadmin
+ setlog</command> kan bli kjørt på en måte som går helt utenom
+ påhakningsgrensesnittet.</para></footnote>
+ Og siden du kan forandre revisjonsegenskaper som går på tvers av
+ den kronolgisk rekkefølgen — du kan forandre enhver egenskap til
+ en revisjon til enhver tid — vil en inkrementell backup av de
+ seneste få revisjonene kanskje ikke fange opp en
+ egenskapsforandring i en revisjon som ble inkludert som del av
+ en tidligere backup.</para>
+ <!-- @ENGLISH {{{
<para>Generally speaking, only the truly paranoid would need to
backup their entire repository, say, every time a commit
occurred. However, assuming that a given repository has some
@@ -5044,7 +5113,20 @@
sufficient redundancy as restoration sources, at least for the
most recent few commits. But it's your data—protect it
as much as you'd like.</para>
+ @ENGLISH }}} -->
+ <para>Vanligvis vil bare den helt paranoide trenge å ta backup av
+ hele depotet, la oss si, hver gang en innlegging skjer.
+ Imidlertid, hvis vi antar at et gitt depot har andre ekstra
+ finkornede mekanismer på plass (som epost for hver innlegging),
+ vil en varm backup av databasen være noe som en
+ depotadministrator vil ønske å inkludere som del av en nattlig
+ systembackup.
+ For de fleste depot vil arkiverte eposter alene gi nok
+ informasjon som gjenopprettelseskilde, i hvert fall for de siste
+ få innleggingene.
+ Men det er dine data — beskytt dem så mye som du vil.</para>
+ <!-- @ENGLISH {{{
<para>Often, the best approach to repository backups is a
diversified one. You can leverage combinations of full and
incremental backups, plus archives of commit emails. The
@@ -5061,6 +5143,23 @@
</footnote>
it should certainly help you recover from those trying
times.</para>
+ @ENGLISH }}} -->
+ <para>Ofte er den beste tilnærmingsmåten til kopier av depotet
+ delt.
+ Du kan sette opp kombinasjoner av fullstendige og inkrementelle
+ backuper, pluss et arkiv med innleggingsmeldinger.
+ Subversionutviklerne tar for eksempel backup av kildekodedepotet
+ etter hver ny revisjon er opprettet, og tar vare på et arkiv med
+ alle eposter som varsler om innlegginger og forandringer i
+ revisjoner og egenskaper.
+ Løsningen din kan være noe lignende, men bør tilpasses dine
+ behov og følge den fine linjen mellom bekvemmelighet og
+ paranoia.
+ Og selv om dette ikke vil redde hardwaren din fra Skjebnens
+ jernhånd,<!-- ¤ <footnote><para>You know—the collective term for
+ all of her <quote>fickle fingers</quote>.</para></footnote> -->
+ vil det helt sikkert hjelpe deg å komme deg på fote igjen etter
+ disse harde tider.</para>
</sect2>
</sect1>
More information about the svnbook-dev
mailing list