[svnbook] r4982 committed - [de] Translation: Branching and Merging...
svnbook at googlecode.com
svnbook at googlecode.com
Thu Feb 12 00:45:16 CST 2015
Revision: 4982
Author: jmfelderhoff at gmx.eu
Date: Thu Feb 12 06:45:07 2015 UTC
Log: [de] Translation: Branching and Merging
** Vendor Branches from Mirrored Sources (part 1)
https://code.google.com/p/svnbook/source/detail?r=4982
Modified:
/branches/1.8/de/book/ch04-branching-and-merging.xml
=======================================
--- /branches/1.8/de/book/ch04-branching-and-merging.xml Wed Feb 11
13:09:17 2015 UTC
+++ /branches/1.8/de/book/ch04-branching-and-merging.xml Thu Feb 12
06:45:07 2015 UTC
@@ -8508,8 +8508,12 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.vendorbr.mirrored-sources">
+<!--
<title>Vendor Branches from Mirrored Sources</title>
+-->
+ <title>Lieferanten-Zweige aus gespiegelten Quellen</title>
+<!--
<para>In the previous section
(<xref linkend="svn.advanced.vendorbr.foreign-repos" />) we
looked at how to implement and maintain a vendor branch when
@@ -8526,13 +8530,41 @@
cleanly as possible. So let's examine an approach to vendor
branches in which the third-party library's various releases
are mirrored within our own repository.</para>
+-->
+ <para>Im vorhergehenden Abschnitt
+ (<xref linkend="svn.advanced.vendorbr.foreign-repos" />) haben
+ wir uns angesehen, wie ein Lieferanten-Zweig angelegt und
+ verwaltet wird, wenn die Zulieferungen über Subversion zu
+ erreichen sind, was der Idealfall bei Lieferanten-Zweigen ist.
+ Subversion kann sehr gut mit Merges von Dingen umgehen, die
+ von Subversion verwaltet wurden. Unglücklicherweise trifft es
+ nicht immer zu, dass Bibliotheken von Drittanbietern
+ öffentlich über Subversion zugreifbar sind. Oftmals hängt ein
+ Projekt von einer Bibliothek ab, die über Wege außerhalb von
+ Subversion ausgeliefert wird, wie etwa Quelltext-Tarballs.
+ Unter derartigen Umständen empfehlen wir dringend, alles zu
+ tun, um diese Informationen außerhalb von Subversion möglichst
+ sauber in Subversion einzupflegen. Lassen Sie uns nun einen
+ Ansatz für Lieferanten-Zweige untersuchen, bei dem die
+ verschiedenen freigegebenen Versionen der
+ Drittanbieter-Bibliothek innerhalb unseres eigenen
+ Projektarchivs gespiegelt werden.</para>
+<!--
<para>Setting up the vendor branch the first time is pretty
simple, really. For our example, we'll assume that libcomplex
1.0.0 is delivered via the common tarball mechanism. To
create our vendor branch, we'll first get the contents of the
libcomplex 1.0.0 tarball into our repository as a read-only
(by convention only) vendor tag of sorts.</para>
+-->
+ <para>Das erstmalige Aufsetzen des Lieferanten-Zweiges ist
+ wirklich recht einfach. Für unser Beispiel nehmen wir an, dass
+ libcomplex 1.0.0 über den verbreiteten Tarball-Mechanismus
+ verteilt wird. Um unseren Lieferanten-Zweig zu erstellen,
+ holen wir zunächst den Inhalt des libcomplex 1.0.0 Tarballs
+ als nur-lesbaren (durch Konvention) Lieferanten-Tag in
+ unser Projektarchiv.</para>
<informalexample>
<screen>
@@ -8546,7 +8578,7 @@
libcomplex-1.0.0/tests/TODO
$ svn import libcomplex-1.0.0 \
http://svn.example.com/projects/vendor/libcomplex-1.0.0 \
- --no-ignore --no-auto-props \
+ --no-ignore --no-auto-props \<!--
-m "Import libcomplex 1.0.0 sources."
Adding libcomplex-custom
Adding libcomplex-custom/README
@@ -8556,11 +8588,38 @@
Adding libcomplex-custom/src/code.h
Adding libcomplex-custom/src/code.c
Transmitting file data .......................................
-Committed revision 1160.
+Committed revision 1160.-->
+ -m "libcomplex 1.0.0 Quellen importieren."
+Füge hinzu libcomplex-custom
+Füge hinzu libcomplex-custom/README
+Füge hinzu libcomplex-custom/LICENSE
+…
+Füge hinzu libcomplex-custom/src
+Füge hinzu libcomplex-custom/src/code.h
+Füge hinzu libcomplex-custom/src/code.c
+Übertrage Daten .......................................
+Revision 1160 übertragen.
$
</screen>
</informalexample>
+<!--
+ <para>Note that in our example, we used
+ the <option>- -no-ignore</option> option during import so that
+ Subversion is sure to pick up every file in the vendor drop
+ and not to omit any of them. We also supply
+ the <option>- -no-auto-props</option> option so that our client
+ doesn't manufacture property information which isn't present
+ in the vendor drop.<footnote><para>Technically, we could let
+ the auto-props feature do its thing, but the key to making
+ that work well is ensuring that each vendor drop gets
+ identical auto-prop treatment.</para></footnote>.</para>
+
+ <para>Now that the first vendor release drop is present in our
+ repository, we can create our vendor branch from it just as we
+ would create any other branch—using <command>svn
+ copy</command>.</para>
+-->
<para>Note that in our example, we used
the <option>--no-ignore</option> option during import so that
Subversion is sure to pick up every file in the vendor drop
More information about the svnbook-dev
mailing list