[svnbook] r4572 committed - Translation: Filtering Repository History
svnbook at googlecode.com
svnbook at googlecode.com
Mon Dec 23 18:53:47 CST 2013
Revision: 4572
Author: jmfelderhoff at gmx.eu
Date: Mon Dec 23 22:11:28 2013 UTC
Log: Translation: Filtering Repository History
http://code.google.com/p/svnbook/source/detail?r=4572
Modified:
/branches/1.6/de/book/ch05-repository-admin.xml
=======================================
--- /branches/1.6/de/book/ch05-repository-admin.xml Mon Dec 23 21:59:10
2013 UTC
+++ /branches/1.6/de/book/ch05-repository-admin.xml Mon Dec 23 22:11:28
2013 UTC
@@ -4513,29 +4513,23 @@
compression (optionally in a completely opaque database
system), attempting manual tweaks is unwise if not quite
difficult, and at any rate strongly discouraged. And once
- data has been stored in your repository, Subversion
- generally doesn't provide an easy way to remove that data.
- <footnote>
- <para>That's rather the reason you use version control at
- all, right?</para>
- </footnote>
- But inevitably, there will be times when you would like to
- manipulate the history of your repository. You might need
- to strip out all instances of a file that was accidentally
- added to the repository (and shouldn't be there for whatever
- reason).
- <footnote>
- <para>Conscious, cautious removal of certain bits of
- versioned data is actually supported by real use cases.
- That's why an <quote>obliterate</quote> feature has been
- one of the most highly requested Subversion features,
- and one which the Subversion developers hope to soon
- provide.</para>
- </footnote>
- Or, perhaps you have multiple projects sharing a
- single repository, and you decide to split them up into
- their own repositories. To accomplish tasks such as these,
- administrators need a more manageable and malleable
+ data has been stored in your repository, Subversion generally
+ doesn't provide an easy way to remove that
+ data.<footnote><para>That's rather the reason you use version
+ control at all, right?</para></footnote> But inevitably, there
+ will be times when you would like to manipulate the history of
+ your repository. You might need to strip out all instances of
+ a file that was accidentally added to the repository (and
+ shouldn't be there for whatever
+ reason).<footnote><para>Conscious, cautious removal of certain
+ bits of versioned data is actually supported by real use
+ cases. That's why an <quote>obliterate</quote> feature has
+ been one of the most highly requested Subversion features, and
+ one which the Subversion developers hope to soon
+ provide.</para></footnote> Or, perhaps you have multiple
+ projects sharing a single repository, and you decide to split
+ them up into their own repositories. To accomplish tasks such
+ as these, administrators need a more manageable and malleable
representation of the data in their repositories—the
Subversion repository dump format.</para>
-->
@@ -4546,31 +4540,25 @@
schwierig und unter allen Umständen nicht angeraten. Sobald
Daten im Projektarchiv gespeichert sind, bietet Subversion im
Allgemeinen keine einfache Möglichkeit, diese Daten zu
- entfernen.
- <footnote>
- <para>Das ist doch überhaupt der Grund dafür,
- Versionskontrolle einzusetzen, oder?</para>
- </footnote>
+ entfernen.<footnote><para>Das ist doch überhaupt der Grund
+ dafür, Versionskontrolle einzusetzen, oder?</para></footnote>
Doch zwangsläufig werden sich Gelegenheiten ergeben, bei denen
Sie die Historie Ihres Projektarchivs manipulieren müssen. Es
könnte sein, dass Sie alle Instanzen einer Datei entfernen
müssen, die versehentlich dem Projektarchiv hinzugefügt worden
ist, aber aus welchen Gründen auch immer nicht hineingehört).
- <footnote>
- <para>Das bewusste, vorsichtige Entfernen bestimmter Teile
- versionierter Daten wird tatsächlich von wirklichen
- Anwendungsfällen verlangt. Das ist der Grund, warum eine
- <quote>Auslösch</quote>-Funktion eine der am häufigsten
- gewünschten Funktionen von Subversion ist, von der die
- Subversion-Entwickler hoffen, sie bald zur Verfügung
- stellen zu können.</para>
- </footnote>
- Oder Sie haben vielleicht mehrere Projekte, die sich ein
- Projektarchiv teilen und entscheiden sich nun, jedem Projekt sein
- eigenes Projektarchiv zu geben. Um Aufgaben wie diese
- bewerkstelligen zu können, benötigen Administratoren eine
- besser handhabbare und bearbeitbare Repräsentation der Daten
- in den Projektarchiven – das
+ <footnote><para>Das bewusste, vorsichtige Entfernen bestimmter
+ Teile versionierter Daten wird tatsächlich von wirklichen
+ Anwendungsfällen verlangt. Das ist der Grund, warum eine
+ <quote>Auslösch</quote>-Funktion eine der am häufigsten
+ gewünschten Funktionen von Subversion ist, von der die
+ Subversion-Entwickler hoffen, sie bald zur Verfügung stellen
+ zu können.</para></footnote> Oder Sie haben vielleicht mehrere
+ Projekte, die sich ein Projektarchiv teilen und entscheiden
+ sich nun, jedem Projekt sein eigenes Projektarchiv zu geben.
+ Um Aufgaben wie diese bewerkstelligen zu können, benötigen
+ Administratoren eine besser handhabbare und bearbeitbare
+ Repräsentation der Daten in den Projektarchiven – das
Subversion-Projektarchiv-Auszugsformat.</para>
<!--
@@ -4660,7 +4648,8 @@
<literal>spreadsheet</literal>. Sie waren miteinander in der
folgenden Anordnung abgelegt:</para>
- <screen>
+ <informalexample>
+ <literallayout>
/
calc/
trunk/
@@ -4674,7 +4663,8 @@
trunk/
branches/
tags/
-</screen>
+</literallayout>
+ </informalexample>
<!--
<para>To get these three projects into their own repositories,
@@ -4685,7 +4675,8 @@
Projektarchivs:</para>
<!--
- <screen>
+ <informalexample>
+ <screen>
$ svnadmin dump /var/svn/repos > repos-dumpfile
* Dumped revision 0.
* Dumped revision 1.
@@ -4694,8 +4685,10 @@
…
$
</screen>
+ </informalexample>
-->
- <screen>
+ <informalexample>
+ <screen>
$ svnadmin dump /var/svn/repos > repos-dumpfile
* Revision 0 ausgegeben.
* Revision 1 ausgegeben.
@@ -4704,6 +4697,7 @@
…
$
</screen>
+ </informalexample>
<!--
<para>Next, run that dump file through the filter, each time
@@ -4715,7 +4709,8 @@
ausgewählt wird. Als Ergebnis erhalten wir drei
Auszugsdateien:</para>
- <screen>
+ <informalexample>
+ <screen>
$ svndumpfilter include calc < repos-dumpfile > calc-dumpfile
…
$ svndumpfilter include calendar < repos-dumpfile > cal-dumpfile
@@ -4724,6 +4719,7 @@
…
$
</screen>
+ </informalexample>
<!--
<para>At this point, you have to make a decision. Each of your
@@ -4761,13 +4757,15 @@
das Verzeichnis <filename>calc</filename> anlegt. Es sollte
etwa wie folgt aussehen:</para>
- <screen>
+ <informalexample>
+ <programlisting>
Node-path: calc
Node-action: add
Node-kind: dir
Content-length: 0
-</screen>
+</programlisting>
+ </informalexample>
<!--
<warning>
@@ -4801,7 +4799,8 @@
ignoriert wird:</para>
<!--
- <screen>
+ <informalexample>
+ <screen>
$ svnadmin create calc
$ svnadmin load - -ignore-uuid calc < calc-dumpfile
<<< Started new transaction, based on original revision 1
@@ -4822,8 +4821,10 @@
…
$
</screen>
+ </informalexample>
-->
- <screen>
+ <informalexample>
+ <screen>
$ svnadmin create calc
$ svnadmin load --ignore-uuid calc < calc-dumpfile
<<< Neue Transaktion basierend auf Originalrevision 1 gestartet
@@ -4844,6 +4845,7 @@
…
$
</screen>
+ </informalexample>
<!--
<para>Both of <command>svndumpfilter</command>'s subcommands
@@ -4932,27 +4934,27 @@
<literal>Node-path</literal> und
<literal>Node-copyfrom-path</literal> ansehen.</para>
- <screen>
+ <informalexample>
+ <programlisting>
…
Node-path: spreadsheet/Makefile
…
-</screen>
+</programlisting>
+ </informalexample>
<!--
<para>If the paths have leading slashes, you should
include leading slashes in the paths you pass to
<command>svndumpfilter include</command> and
<command>svndumpfilter exclude</command> (and if they don't,
- you shouldn't). Further, if your dump file has an inconsistent
- usage of leading slashes for some reason,
- <footnote>
- <para>While <command>svnadmin dump</command> has a
- consistent leading slash policy (to not include
- them), other programs that generate dump data might
- not be so consistent.</para>
- </footnote>
- you should probably normalize those paths so that they all
- have, or all lack, leading slashes.</para>
+ you shouldn't). Further, if your dump file has an
+ inconsistent usage of leading slashes for some
+ reason,<footnote><para>While <command>svnadmin dump</command>
+ has a consistent leading slash policy (to not include them),
+ other programs that generate dump data might not be so
+ consistent.</para></footnote> you should probably normalize
+ those paths so that they all have, or all lack, leading
+ slashes.</para>
-->
<para>Falls die Pfade führende Schrägstriche haben, sollten auch
Sie Schrägstriche in den Pfaden angeben, die Sie an
@@ -4961,15 +4963,13 @@
sie keine haben, sollten Sie auch keine angeben). Falls Ihre
Auszugsdatei aus irgendwelchen Gründen einen nicht
konsistenten Gebrauch von führenden Schrägstrichen macht,
- <footnote>
- <para>Obwohl <command>svnadmin dump</command> ein
- konsistentes Vorgehen bezüglich führender Schrägstriche
- vorweisen kann (indem es sie nicht einfügt), sind andere
- Programme, die Auszugsdateien erzeugen eventuell nicht so
- konsistent.</para>
- </footnote>
- sollten Sie diese Pfade normalisieren, so dass sie alle
- entweder Schrägstriche haben oder nicht.</para>
+ <footnote><para>Obwohl <command>svnadmin dump</command> ein
+ konsistentes Vorgehen bezüglich führender Schrägstriche
+ vorweisen kann (indem es sie nicht einfügt), sind andere
+ Programme, die Auszugsdateien erzeugen eventuell nicht so
+ konsistent.</para></footnote> sollten Sie diese Pfade
+ normalisieren, so dass sie alle entweder Schrägstriche haben
+ oder nicht.</para>
<!--
<para>Also, copied paths can give you some trouble.
More information about the svnbook-dev
mailing list