[svnbook] r5001 committed - [de] Changed "übergeben" to "übertragen" to concur with Subversions...
svnbook at googlecode.com
svnbook at googlecode.com
Tue Feb 24 00:48:51 CST 2015
Revision: 5001
Author: jmfelderhoff at gmx.eu
Date: Tue Feb 24 06:48:19 2015 UTC
Log: [de] Changed "übergeben" to "übertragen" to concur with
Subversions
German locale output.
https://code.google.com/p/svnbook/source/detail?r=5001
Modified:
/branches/1.8/de/book/appa-quickstart.xml
/branches/1.8/de/book/appb-svn-for-cvs-users.xml
/branches/1.8/de/book/appc-webdav.xml
/branches/1.8/de/book/ch01-fundamental-concepts.xml
/branches/1.8/de/book/ch02-basic-usage.xml
/branches/1.8/de/book/ch04-branching-and-merging.xml
/branches/1.8/de/book/ch05-repository-admin.xml
/branches/1.8/de/book/ch06-server-configuration.xml
/branches/1.8/de/book/ch07-customizing-svn.xml
/branches/1.8/de/book/ch08-embedding-svn.xml
/branches/1.8/de/book/ref-svn.xml
/branches/1.8/de/book/ref-svnmucc.xml
=======================================
--- /branches/1.8/de/book/appa-quickstart.xml Tue Nov 25 15:14:00 2014 UTC
+++ /branches/1.8/de/book/appa-quickstart.xml Tue Feb 24 06:48:19 2015 UTC
@@ -486,7 +486,7 @@
version of your file to the repository.</para>
-->
<para>Rufen Sie <userinput>svn commit</userinput> auf, um die
- neue Version Ihrer Datei an das Projektarchiv zu übergeben.
+ neue Version Ihrer Datei an das Projektarchiv zu übertragen.
</para>
</listitem>
<listitem>
=======================================
--- /branches/1.8/de/book/appb-svn-for-cvs-users.xml Tue Nov 25 15:14:00
2014 UTC
+++ /branches/1.8/de/book/appb-svn-for-cvs-users.xml Tue Feb 24 06:48:19
2015 UTC
@@ -224,7 +224,7 @@
bestimmte Ansammlung von Verzeichniseinträgen und Eigenschaften.
Angenommen, wir beginnen nun damit, Dateien dem Verzeichnis
<filename>foo</filename> hinzuzufügen und wegzunehmen und diese
- Änderungen dann zu übergeben. Es wäre eine Lüge, zu behaupten,
+ Änderungen dann zu übertragen. Es wäre eine Lüge, zu behaupten,
dass wir immer noch Revision 5 von <filename>foo</filename>
hätten. Wenn wir allerdings die Revisionsnummer von
<filename>foo</filename> nach der Übergabe erhöht hätten, wäre
@@ -244,7 +244,7 @@
contain <quote>imperfect</quote> directory revisions.</para>
-->
<para>Subversion behandelt dieses Problem, indem es
- stillschweigend übergebene Hinzufügungen sowie Löschungen im
+ stillschweigend übertragene Hinzufügungen sowie Löschungen im
<filename>.svn</filename>-Bereich mitverfolgt. Wenn Sie
schließlich <userinput>svn update</userinput> aufrufen, wird
alles in Bezug auf das Projektarchiv glattgezogen und die neue
@@ -267,12 +267,12 @@
-->
<para>Auf ähnliche Art ergibt sich ein Problem, wenn Sie
versuchen, Eigenschafts-Änderungen an einem Verzeichnis zu
- übergeben. Normalerweise würde die Übergabe die lokale
+ übertragen. Normalerweise würde die Übergabe die lokale
Revisionsnummer erhöhen, was jedoch eine Lüge wäre, da
Hinzufügungen oder Löschungen vorhanden sein könnten, die das
Verzeichnis noch nicht mitbekommen hat, da es nicht aktualisiert
worden ist. <emphasis>Deshalb dürfen Sie Änderungen an
- Verzeichnis-Eigenschaften nicht übergeben, bevor Sie das Verzeichnis
+ Verzeichnis-Eigenschaften nicht übertragen, bevor Sie das Verzeichnis
aktualisiert haben.</emphasis></para>
<!--
@@ -736,7 +736,7 @@
zu Problemen geführt, da CVS nicht genug macht. Viele Benutzer
vergessen das <literal>C</literal> nachdem es über ihr Terminal
geschossen ist (oder sehen es nicht). Oftmals vergessen sie,
- dass überhaupt Konfliktmarkierungen vorhanden sind und übergeben
+ dass überhaupt Konfliktmarkierungen vorhanden sind und übertragen
versehentlich Dateien, die diese Konfliktmarkierungen
enthalten.</para>
=======================================
--- /branches/1.8/de/book/appc-webdav.xml Tue Feb 3 17:18:07 2015 UTC
+++ /branches/1.8/de/book/appc-webdav.xml Tue Feb 24 06:48:19 2015 UTC
@@ -384,7 +384,7 @@
<para>Bevor Sie dieses Merkmal aktivieren, sollten Sie verstehen,
worauf Sie sich einlassen. WebDAV-Clients neigen dazu,
<emphasis>viele</emphasis> Schreibanfragen abzusetzen, was zu
- einer riesigen Menge automatisch übergebener Revisionen führt.
+ einer riesigen Menge automatisch übertragener Revisionen führt.
Beim Sichern von Daten beispielsweise geben viele Clients ein
<literal>PUT</literal> einer 0-Byte-Datei aus (um somit einen
Namen zu reservieren), gefolgt von einem weiteren
=======================================
--- /branches/1.8/de/book/ch01-fundamental-concepts.xml Tue Feb 3 17:18:07
2015 UTC
+++ /branches/1.8/de/book/ch01-fundamental-concepts.xml Tue Feb 24 06:48:19
2015 UTC
@@ -268,7 +268,7 @@
<quote>versionskontroll-bewusst</quote> sein müssen, um die
Daten zu lesen und zu schreiben. Die Aufgabe, die Arbeitskopie
zu verwalten und Änderungen an ihrem Inhalt zum und vom
- Projektarchiv zu übergeben, fällt genau der Client-Software
+ Projektarchiv zu übertragen, fällt genau der Client-Software
des Versions-Kontroll-Systems zu.</para>
</sect2>
@@ -1557,7 +1557,7 @@
-->
<para>Die Datei im Arbeitsverzeichnis ist unverändert, und
keinerlei Änderungen an der Datei sind seit der
- Arbeitsrevision an das Projektarchiv übergeben worden. Ein
+ Arbeitsrevision an das Projektarchiv übertragen worden. Ein
<command>svn commit</command> der Datei würde nichts
machen, und ein <command>svn update</command> der Datei
auch nicht.</para>
@@ -1582,9 +1582,9 @@
-->
<para>Die Datei wurde im Arbeitsverzeichnis geändert, und
keinerlei Änderungen an der Datei sind seit der letzten
- Aktualisierung an das Projektarchiv übergeben worden. Es
+ Aktualisierung an das Projektarchiv übertragen worden. Es
gibt lokale Änderungen, die noch nicht an das Projektarchiv
- übergeben worden sind, so dass ein <command>svn
+ übertragen worden sind, so dass ein <command>svn
commit</command> der Datei Ihre Änderungen erfolgreich
veröffentlichen würde, und ein <command>svn
update</command> der Datei nichts tun würde.</para>
@@ -2098,7 +2098,7 @@
eine Aktion, die in das Projektarchiv schreibt keine
Aktion zur Folge hat, die aus dem Projektarchiv liest und
umgekehrt. Wenn Sie bereit sind, neue Änderungen an das
- Projektarchiv zu übergeben, heißt das noch lange nicht,
+ Projektarchiv zu übertragen, heißt das noch lange nicht,
dass Sie auch die Änderungen anderer haben möchten. Und
wenn Sie noch an Änderungen arbeiten, sollte <command>svn
update</command> elegant die Änderungen aus dem
@@ -2314,7 +2314,7 @@
destroying changes you've not yet seen.</para>
-->
<para>Erstens kann die Löschung einer Datei oder eines
- Verzeichnisses nicht an das Projektarchiv übergeben werden,
+ Verzeichnisses nicht an das Projektarchiv übertragen werden,
wenn die Datei oder das Verzeichnis nicht ganz aktuell ist.
Falls eine neuere Version im Projektarchiv existiert, wird Ihr
Löschversuch abgelehnt, um zu vermeiden, dass Sie
@@ -2331,7 +2331,7 @@
destroy properties you've not yet seen.</para>
-->
<para>Zweitens können Sie keine Änderungen an Metadaten eines
- Verzeichnisses an das Projektarchiv übergeben, wenn das
+ Verzeichnisses an das Projektarchiv übertragen, wenn das
Verzeichnis nicht ganz aktuell ist. In
<xref linkend="svn.advanced"/> werden Sie lernen, wie man
<quote>Eigenschaften</quote> an Objekte hängt. Die
=======================================
--- /branches/1.8/de/book/ch02-basic-usage.xml Wed Dec 17 08:26:21 2014 UTC
+++ /branches/1.8/de/book/ch02-basic-usage.xml Tue Feb 24 06:48:19 2015 UTC
@@ -863,7 +863,7 @@
-->
<para>Sofern Sie nicht bereit sind, das Hinzufügen einer neuen
Datei oder eines neuen Verzeichnisses oder Änderungen an
- bestehenden Objekten an das Projektarchiv zu übergeben, besteht
+ bestehenden Objekten an das Projektarchiv zu übertragen, besteht
keine Notwendigkeit, dem Subversion-Server mitzuteilen, dass Sie
irgendetwas gemacht haben.</para>
@@ -1066,7 +1066,7 @@
create the newest versions of all the things you modified.
Now others can see your work, too!</para>
-->
- <para><emphasis>Veröffentlichen (übergeben) Sie Ihre
+ <para><emphasis>Veröffentlichen (übertragen) Sie Ihre
Änderungen.</emphasis> Der Befehl <command>svn
commit</command> überträgt Ihre Änderungen in das
Projektarchiv, in dem sie, falls sie angenommen werden, die
@@ -1149,7 +1149,7 @@
-->
<para>In diesem Fall sieht es so aus, dass jemand Änderungen
sowohl an <filename>foo.c</filename> als auch an
- <filename>bar.c</filename> übergeben hat, seit Sie das letzte
+ <filename>bar.c</filename> übertragen hat, seit Sie das letzte
Mal aktualisiert haben, und Subversion hat Ihre Arbeitskopie
aktualisiert, damit sie beide Änderungen enthält.</para>
@@ -1232,7 +1232,7 @@
oder Verschieben <quote>einzuplanen</quote>. Diese Änderungen
können sofort in Ihrer Arbeitskopie stattfinden, jedoch wird
im Projektarchiv nichts hinzugefügt oder gelöscht bevor Sie
- die Änderungen übergeben haben.</para>
+ die Änderungen übertragen haben.</para>
<sidebar>
<!--
@@ -1288,7 +1288,7 @@
won't prevent Windows users from performing their other
Subversion-related activities.</para> </sidebar>
-->
- <para>Wenn ein Symlink in Subversion übergeben wird, merkt
+ <para>Wenn ein Symlink in Subversion übertragen wird, merkt
sich Subversion sowohl, dass die Datei eigentlich ein
Symlink ist, als auch das Objekt, auf das der Symlink
<quote>zeigt</quote>. Wenn dieser Symlink auf einem
@@ -1340,7 +1340,7 @@
<para>Verwenden Sie diesen Befehl, um die Datei, das
Verzeichnis oder den symbolischen Link
<filename>FOO</filename> zum Hinzufügen in das
- Projektarchiv vormerken. Wenn Sie das nächste Mal übergeben,
+ Projektarchiv vormerken. Wenn Sie das nächste Mal übertragen,
wird <filename>FOO</filename> ein Kind seines
Elternverzeichnisses. Beachten Sie, dass alles unterhalb
von <filename>FOO</filename> zum Hinzufügen vorgemerkt
@@ -1388,7 +1388,7 @@
Arbeitskopie entfernt, falls es eine Datei oder ein Link
ist. Falls <filename>FOO</filename> ein Verzeichnis ist,
wird es nicht gelöscht, sondern zum Löschen vorgemerkt.
- Wenn Sie Ihre Änderungen übergeben, wird das gesamte
+ Wenn Sie Ihre Änderungen übertragen, wird das gesamte
Verzeichnis <filename>FOO</filename> aus der
Arbeitskopie und dem Projektarchiv entfernt.
<footnote><para>Selbstverständlich wird nichts jemals
@@ -1552,9 +1552,9 @@
der Hauptvorteil einer Arbeitskopie darin, dass sie sich als
eine Art <quote>Bereitstellungsraum</quote> verwenden lässt.
Sie können sicherstellen, dass die Änderungen, die Sie
- übergeben möchten, im Gesamtzusammenhang Ihres Projektes
+ übertragen möchten, im Gesamtzusammenhang Ihres Projektes
einen Sinn ergeben, bevor sie tatsächlich in das
- Projektarchiv übergeben werden. Und selbstverständlich
+ Projektarchiv übertragen werden. Und selbstverständlich
können diese vorbereiteten Änderungen so einfach oder so
kompliziert wie notwendig sein, und dennoch bei der Übergabe
in einer einzigen neuen Revision münden.</para>
@@ -1598,7 +1598,7 @@
anzusehen. Dadurch, dass Sie die Änderungen noch einmal
begutachten, können Sie eine genauere
<firstterm>Protokollnachricht</firstterm> schreiben (eine
- menschenlesbare Beschreibung der übergebenen Änderungen, die
+ menschenlesbare Beschreibung der übertragenen Änderungen, die
neben ihnen im Projektarchiv gespeichert wird). Es könnte auch
sein, dass Sie feststellen, versehentlich eine Datei geändert
zu haben, und dass Sie vor der Übergabe diese Änderung
@@ -1828,7 +1828,7 @@
Ihrer Arbeitskopie haben (und konnten beim
Aktualisieren nicht automatisch aufgelöst werden). Sie
müssen den Konflikt auflösen, bevor Sie Ihre
- Änderungen in das Projektarchiv übergeben können.</para>
+ Änderungen in das Projektarchiv übertragen können.</para>
</listitem>
</varlistentry>
@@ -2176,7 +2176,7 @@
handelt, die Unterschiede an einer oder mehreren Dateien
beschreiben. Daher können Sie die in Ihrer Arbeitskopie
vorgenommenen Änderungen mit jemanden teilen, ohne die
- Änderungen erst übergeben zu müssen, indem Sie aus der
+ Änderungen erst übertragen zu müssen, indem Sie aus der
umgeleiteten Ausgabe des Befehls <command>svn diff</command>
eine Patch-Datei erzeugen:</para>
@@ -2485,7 +2485,7 @@
<filename>bar.c</filename> hineinzubringen, festgestellt hat,
dass einige dieser Änderungen mit lokalen Änderungen
kollidieren, die Sie an dieser Datei in Ihrer Arbeitskopie
- vorgenommen, jedoch noch nicht übergeben haben. Vielleicht hat
+ vorgenommen, jedoch noch nicht übertragen haben. Vielleicht hat
jemand dieselbe Textzeile wie Sie geändert. Wie dem auch sei,
Subversion markiert diese Datei umgehend als konfliktbehaftet.
Dann fragt es Sie, wie Sie mit diesem Problem umgehen möchten,
@@ -3252,7 +3252,7 @@
<para>An dieser Stelle erlaubt Subversion Sally
<emphasis>nicht</emphasis>, die Datei
<filename>sandwich.txt</filename> an das Projektarchiv zu
- übergeben, solange die drei temporären Dateien nicht
+ übertragen, solange die drei temporären Dateien nicht
entfernt werden:</para>
<informalexample>
@@ -3518,7 +3518,7 @@
bekommt.<footnote><para>Und wenn Sie danach fragen, wird man
Sie wahrscheinlich auf einer Schiene aus der Stadt
tragen.</para></footnote> Sobald Sie sich über die zu
- übergebenden Änderungen einig sind, können Sie Ihre Datei
+ übertragenden Änderungen einig sind, können Sie Ihre Datei
bearbeiten und die Konfliktmarken entfernen:</para>
<informalexample>
@@ -3542,7 +3542,7 @@
-->
<para>Verwenden Sie jetzt <command>svn resolve</command>, und
Sie sind bereit, Ihre Änderungen an das Projektarchiv zu
- übergeben:</para>
+ übertragen:</para>
<informalexample>
<screen>
@@ -3715,7 +3715,7 @@
-->
<para>Endlich! Sie haben die Bearbeitung abgeschlossen, Sie
haben alle Änderungen vom Server eingearbeitet, und Sie sind
- bereit, Ihre Änderungen an das Projektarchiv zu übergeben.</para>
+ bereit, Ihre Änderungen an das Projektarchiv zu übertragen.</para>
<!--
<para>The <command>svn commit</command> command sends all of
@@ -3728,7 +3728,7 @@
-->
<para>Der Befehl <command>svn commit</command> schickt all Ihre
Änderungen zum Projektarchiv. Wenn Sie eine Änderung
- übergeben, müssen Sie einen Protokolleintrag erstellen, der
+ übertragen, müssen Sie einen Protokolleintrag erstellen, der
die Änderung beschreibt. Dieser Eintrag wird mit der von Ihnen
erzeugten neuen Revision verknüpft. Wenn Ihr
Eintrag kurz ist, können Sie ihn mit der Option
@@ -3917,7 +3917,7 @@
<emphasis>going into</emphasis> it.</para>
-->
<para>Ihr Subversion-Projektarchiv ist wie eine Zeitmaschine. Es legt
- einen Eintrag für jede jemals übergebene Änderung an und erlaubt
+ einen Eintrag für jede jemals übertragene Änderung an und erlaubt
Ihnen, diese Geschichte durch die Untersuchung sowohl ehemaliger
Datei- und Verzeichnisversionen als auch der begleitenden
Metadaten zu erforschen. Mit einem einzigen Subversion-Befehl
@@ -4115,7 +4115,7 @@
repository:</para>
-->
<para>Wird eine einzelne Nummer mit <option>--revision</option>
- (<option>-r</option>) übergeben, wird die Arbeitskopie mit
+ (<option>-r</option>) übertragen, wird die Arbeitskopie mit
der angegebenen Revision im Projektarchiv verglichen:</para>
<informalexample>
@@ -4153,7 +4153,7 @@
-->
<para>Werden zwei Revisionsnummern durch einen Doppelpunkt
getrennt mit <option>--revision</option>
- (<option>-r</option>) übergeben, werden die beiden
+ (<option>-r</option>) übertragen, werden die beiden
Revisionen direkt miteinander verglichen:</para>
<informalexample>
@@ -4374,7 +4374,7 @@
<title>Why Does svn log Not Show Me What I
Just Committed?</title>
-->
- <title>Warum zeigt mir svn log nicht, was ich gerade übergeben
+ <title>Warum zeigt mir svn log nicht, was ich gerade übertragen
habe?</title>
<!--
@@ -4397,14 +4397,14 @@
log</command> by using the <option>- -revision</option>
(<option>-r</option>) option.</para>
-->
- <para>Wenn Sie Ihre Änderungen an das Projektarchiv übergeben und
+ <para>Wenn Sie Ihre Änderungen an das Projektarchiv übertragen und
sofort <userinput>svn log</userinput> ohne Argumente
eingeben, wird Ihnen vielleicht auffallen, dass Ihre letzte
Änderung nicht in der Liste der Protokolleinträge
auftaucht. Das liegt an der Kombination des Verhaltens von
<command>svn commit</command> und dem Standardverhalten von
<command>svn log</command>. Wenn Sie Änderungen an das
- Projektarchiv übergeben, erhöht <command>svn</command> zunächst
+ Projektarchiv übertragen, erhöht <command>svn</command> zunächst
nur die Revision der Dateien (und Verzeichnisse) die es
übernimmt, so dass das Elternverzeichnis normalerweise auf
der älteren Revision verbleibt (siehe <xref
@@ -4412,7 +4412,7 @@
die Erklärung, warum das so ist). <command>svn log</command>
holt dann standardmäßig die Geschichte des Verzeichnisses in
der gegenwärtigen Revision, und so kommt es, dass Sie die
- neu übergebenen Änderungen nicht sehen. Die Lösung besteht
+ neu übertragenen Änderungen nicht sehen. Die Lösung besteht
entweder in einer Aktualisierung Ihrer Arbeitskopie oder
indem Sie dem Befehl <command>svn log</command> ausdrücklich
mit der Option <option>--revision</option>
@@ -4972,9 +4972,9 @@
-->
<para>Viele Subversion-Neulinge versuchen das vorangehende
<command>svn update</command>-Beispiel zu verwenden, um
- übergebene Änderungen <quote>rückgängig</quote> zu machen,
+ übertragene Änderungen <quote>rückgängig</quote> zu machen,
was allerdings nicht funktioniert, da Sie keine Änderungen
- übergeben können, die Sie durch das zeitliche Zurücksetzen
+ übertragen können, die Sie durch das zeitliche Zurücksetzen
einer Arbeitskopie erhalten haben, falls die geänderten
Dateien neuere Revisionen haben. Siehe <xref
linkend="svn.branchmerge.basicmerging.resurrect"/> für eine
@@ -5256,10 +5256,10 @@
Dateiinhalten gesprochen. Wenn Sie und Ihre Mitarbeiter
überlappende Änderungen innerhalb derselben Datei vornehmen,
zwingt Sie Subversion dazu, diese Änderungen zusammenzuführen,
- bevor Sie sie übergeben können.<footnote><para>Natürlich
+ bevor Sie sie übertragen können.<footnote><para>Natürlich
<emphasis>könnten</emphasis> Sie Dateien, die
Konfliktmarkierungen enthalten, als konfliktfrei erklären und
- übergeben, wenn Sie es wirklich wollten, doch das wird in der
+ übertragen, wenn Sie es wirklich wollten, doch das wird in der
Praxis kaum gemacht.</para></footnote></para>
<!--
@@ -5295,7 +5295,7 @@
verschieben oder löschen, an der Sie noch arbeiten? Vielleicht
gab es ein Verständnisproblem oder die eine Person glaubt, die
Datei soll gelöscht werden, während die andere Person noch
- Änderungen an der Datei übergeben will. Vielleicht haben Ihre
+ Änderungen an der Datei übertragen will. Vielleicht haben Ihre
Mitarbeiter ja auch etwas Refactoring betrieben und dabei
Dateien umbenannt und Verzeichnisse verschoben. Falls Sie noch
an diesen Dateien gearbeitet haben, müssten diese Änderungen auf
@@ -5683,7 +5683,7 @@
resolved:</para>
-->
<para><filename>bar.c</filename> heißt nun Opfer eines
- Baumkonfliktes. Sie kann nicht übergeben werden, bevor der
+ Baumkonfliktes. Sie kann nicht übertragen werden, bevor der
Konflikt aufgelöst wird:</para>
<informalexample>
@@ -5932,7 +5932,7 @@
the extra work he caused for you.</para>
-->
<para>Sie haben nun Ihren ersten Baumkonflikt aufgelöst! Sie
- können Ihre Änderungen übergeben und Harry in der Kaffeepause
+ können Ihre Änderungen übertragen und Harry in der Kaffeepause
erzählen, welche Mehrarbeit er Ihnen bereitet hat.</para>
</sect2>
=======================================
--- /branches/1.8/de/book/ch04-branching-and-merging.xml Fri Feb 20
16:38:24 2015 UTC
+++ /branches/1.8/de/book/ch04-branching-and-merging.xml Tue Feb 24
06:48:19 2015 UTC
@@ -250,7 +250,7 @@
beseitigt. Sallys Arbeit hängt davon ab, dass die letzte Version
des Projektes (in <filename>/calc/trunk</filename>) stets
benutzbar ist. Wenn Sie nun damit beginnen, Stück für Stück Ihre
- Änderungen zu übergeben, werden Sie die Dinge für Sally (und
+ Änderungen zu übertragen, werden Sie die Dinge für Sally (und
auch für andere Teammitglieder) bestimmt in Unordnung
bringen.</para>
@@ -281,7 +281,7 @@
<para>Eine Strategie wäre es, sich in ein Loch zu verkriechen: Sie
können für eine Woche oder zwei den Informationsaustausch
einstellen, und die Dateien Ihrer Arbeitskopie ausräumen und
- umorganisieren, ohne Änderungen zu übergeben oder die
+ umorganisieren, ohne Änderungen zu übertragen oder die
Arbeitskopie zu aktualisieren, bevor Sie mit Ihrer Arbeit
vollständig fertig sind. Das wirft allerdings einige Probleme
auf. Erstens ist das nicht sehr sicher. Falls Ihrer Arbeitskopie
@@ -301,7 +301,7 @@
Änderungen fertig sind, sehr schwierig sein, Ihr Arbeitsergebnis
wieder mit dem Hauptteil der Quelltexte Ihrer Firma
zusammenzuführen. Sally (und andere) hätten viele andere
- Änderungen ins Projektarchiv übergeben haben können, die sich
+ Änderungen ins Projektarchiv übertragen haben können, die sich
schwer in Ihre Arbeitskopie einarbeiten lassen, wenn Sie
schließlich nach Wochen der Isolierung <command>svn
update</command> ausführen.</para>
@@ -627,7 +627,7 @@
-->
<para>An dieser Arbeitskopie ist nichts besonders; sie spiegelt
bloß ein anderes Verzeichnis im Projektarchiv wider. Wenn Sie
- Änderungen übergeben, wird sie Sally jedoch nicht sehen, wenn
+ Änderungen übertragen, wird sie Sally jedoch nicht sehen, wenn
sie aktualisiert, da sie eine Arbeitskopie von
<filename>/calc/trunk</filename> hat. (Stellen Sie sicher,
dass Sie <xref linkend="svn.branchmerge.switchwc"/> weiter
@@ -3278,7 +3278,7 @@
rückgängig zu machen, und versuchen Sie den Befehl erneut mit
unterschiedlichen Optionen. Der Abgleich ist solange nicht
endgültig, bis Sie mit <command>svn commit</command> das
- Ergebnis übergeben.</para>
+ Ergebnis übertragen.</para>
</sect2>
@@ -3307,15 +3307,15 @@
-->
<para>Sehr häufig wird <command>svn merge</command> verwendet,
um eine Änderung rückgängig zu machen, die bereits an das
- Projektarchiv übergeben worden war. Nehmen wir einmal an, Sie
+ Projektarchiv übertragen worden war. Nehmen wir einmal an, Sie
arbeiten fröhlich in einer Arbeitskopie von
<filename>/calc/trunk</filename> und entdecken, dass die
damaligen Änderungen an verschiedenen Quelltext-Dateien in
- Revision 392 völlig falsch waren. Sie hätten nie übergeben
+ Revision 392 völlig falsch waren. Sie hätten nie übertragen
werden sollen. Sie können <command>svn merge</command>
verwenden, um die Änderung in Ihrer Arbeitskopie
<quote>zurückzunehmen</quote>, und dann die lokale Änderung an
- das Projektarchiv übergeben. Sie müssen hierfür nur eine
+ das Projektarchiv übertragen. Sie müssen hierfür nur eine
<emphasis>umgekehrte</emphasis> Differenz angeben. (Sie machen
das durch die Angabe von <option>--revision 303:302</option>
oder durch das äquivalente <option>--change -303</option>.)
@@ -3455,7 +3455,7 @@
<literal>HEAD</literal> eines Projektes interessiert. Es gibt
jedoch Spezialfälle, in denen Sie wirklich alle Beweise der
Übergabe vernichten möchten. (Vielleicht hat jemand ein
- vertrauliches Dokument in das Projektarchiv übergeben.) Das ist
+ vertrauliches Dokument in das Projektarchiv übertragen.) Das ist
leider nicht so einfach, da Subversion absichtlich so
konstruiert wurde, dass es niemals Informationen
verliert. Revisionen sind unveränderliche Bäume, die
@@ -4595,7 +4595,7 @@
verwendet, um Änderungen rückgängig zu machen. Wenn
diese Technik dazu verwendet wird, um eine Änderung in
der Geschichte eines Objektes zurückzunehmen (z.B. r5
- an den Stamm übergeben, und dann sofort r5 mit
+ an den Stamm übertragen, und dann sofort r5 mit
<userinput>svn merge . -c -5</userinput> rückgängig
machen), hat dies keine Auswirkungen auf die
aufgezeichneten
@@ -4742,7 +4742,7 @@
und dann <userinput>svn merge ^/trunk -c 58</userinput> in
der so erstellten Arbeitskopie aufrufen. Subversion weiß,
dass die in Revision 53 an <filename>^/trunk</filename>
- übergebenen Änderungen bereits in der natürlichen Historie
+ übertragenen Änderungen bereits in der natürlichen Historie
des Ziels vorhanden sind, so dass sie nicht erneut
zusammengeführt werden müssen. Letzten Endes
<emphasis>ist</emphasis> es das primäre Ziel der
@@ -5616,7 +5616,7 @@
via a sync merge:</para>
-->
<para>Obwohl es zutrifft, dass Sie diese drei Zeilen in Revision
- 352 übergeben haben, sind zwei davon tatsächlich von Sally in
+ 352 übertragen haben, sind zwei davon tatsächlich von Sally in
Revision 348 geschrieben worden und sind durch einen
Synchronisierungs-Merge in Ihren Zweig geraten:</para>
@@ -5682,12 +5682,12 @@
different objects in the repository. They share no history
or <quote>ancestry.</quote></para>
-->
- <para>Nehmen wir an, Sie übergeben Revision 100, die eine
+ <para>Nehmen wir an, Sie übertragen Revision 100, die eine
Änderung an der Datei <filename>foo.c</filename> beinhaltet.
Dann ist <filename>foo.c at 99</filename> ein
<quote>Vorfahre</quote> von <filename>foo.c at 100</filename>.
Wenn Sie dagegen in Revision 101 die Löschung von
- <filename>foo.c</filename> übergeben und in Revision 102 eine
+ <filename>foo.c</filename> übertragen und in Revision 102 eine
neue Datei mit demselben Namen hinzufügen, hat es zwar den
Anschein, dass <filename>foo.c at 99</filename> und
<filename>foo.c at 102</filename> in Beziehung zueinander stehen
@@ -5953,7 +5953,7 @@
einiger Bearbeitungen ist) und die ursprüngliche Datei
gelöscht. Zwischenzeitlich hat Sally in r472 auf
<filename>/calc/trunk</filename> selber einige Verbesserungen
- an <filename>integer.c</filename> übergeben:</para>
+ an <filename>integer.c</filename> übertragen:</para>
<informalexample>
<screen>
@@ -6128,7 +6128,7 @@
<para>Wenn Sie und Ihr Team auf die Merge-Verfolgung von
Subversion angewiesen sind, sollten Sie Ihr Projektarchiv
dergestalt konfigurieren, dass ältere Clients daran gehindert
- werden, Änderungen zu übergeben. Die einfache Methode hierfür
+ werden, Änderungen zu übertragen. Die einfache Methode hierfür
ist es, den <quote>Fähigkeiten</quote>-Parameter im
<literal>start-commit</literal> Hook-Skript zu untersuchen.
Wenn der Client meldet, dass er mit
@@ -6186,7 +6186,7 @@
# wird:
#
# [1] REPOS-PATH (der Pfad zu diesem Projektarchiv)
-# [2] USER (der authentisierte Anwender, der übergeben möchte)
+# [2] USER (der authentisierte Anwender, der übertragen möchte)
# [3] CAPABILITIES (eine vom Client durch Doppelpunkte getrennte
# Liste von Leistungsmerkmalen; siehe Anmerkung
# unten)
@@ -6582,7 +6582,7 @@
Unterverzeichnisse aus unterschiedlichen Projektarchiv-Orten
enthält, funktioniert sie immer noch normal. Wenn Sie
aktualisieren, erhalten Sie entsprechende Patches für jeden
- Teilbaum. Wenn Sie übergeben, werden Ihre lokalen Änderungen
+ Teilbaum. Wenn Sie übertragen, werden Ihre lokalen Änderungen
nach wie vor als eine einzelne atomare Änderung auf das
Projektarchiv angewendet.</para>
@@ -6875,7 +6875,7 @@
<literal>HEAD</literal> zum Zeitpunkt, an dem Sie die Kopie
erstellt haben. Natürlich können Sie auch angeben, welche
Revision Sie genau kopieren möchten, für den Fall, dass jemand
- anderes Änderungen an das Projekt übergeben haben könnte,
+ anderes Änderungen an das Projekt übertragen haben könnte,
während Sie nicht hingeschaut haben. Wenn Sie also wissen,
dass Revision 901 von <filename>/calc/trunk</filename> genau
die Momentaufnahme ist, die Sie möchten, können Sie sie mit
@@ -6904,7 +6904,7 @@
<emphasis>Menschen</emphasis> sich entschieden haben, es so zu
betrachten: Solange niemand etwas an das Verzeichnis übergibt,
bleibt es für immer eine Momentaufnahme. Wenn jemand damit
- beginnt, etwas dorthin zu übergeben, wird es ein Zweig.</para>
+ beginnt, etwas dorthin zu übertragen, wird es ein Zweig.</para>
<!--
<para>If you are administering a repository, there are two
@@ -6928,14 +6928,14 @@
Sie Ihre Tags kopieren möchten; stellen Sie sicher, dass alle
Benutzer wissen, wie sie ihre zu kopierenden Verzeichnisse
behandeln sollen, d.h., stellen Sie sicher, dass sie nichts
- dorthin übergeben. Der zweite Ansatz ist etwas paranoider: Sie
+ dorthin übertragen. Der zweite Ansatz ist etwas paranoider: Sie
können eins der Zugriffskontrollskripte verwenden, die mit
Subversion ausgeliefert werden, um zu verhindern, dass
irgendjemand etwas anderes im Tag-Bereich macht, als dort neue
Kopien zu erzeugen (siehe <xref linkend="svn.serverconfig"/>).
Der paranoide Ansatz ist normalerweise nicht notwendig. Falls
ein Benutzer versehentlich eine Änderung an ein
- Tag-Verzeichnis übergeben hat, können Sie die Änderung einfach
+ Tag-Verzeichnis übertragen hat, können Sie die Änderung einfach
rückgängig machen, wie im vorhergehenden Abschnitt
beschrieben. Schließlich handelt es sich um
Versionskontrolle!</para>
@@ -7421,7 +7421,7 @@
Funktionen <filename>/calc/trunk</filename> hinzufügen,
während Sie zum Grundsatz erklären, dass ausschließlich
Fehlerbehebungen an
- <filename>/calc/branches/stable-1.0</filename> übergeben
+ <filename>/calc/branches/stable-1.0</filename> übertragen
werden. Das heißt, während auf dem Stamm weitergearbeitet
wird, pickt jemand selektiv Fehlerbehebungen hinüber auf den
stabilen Zweig. Selbst wenn die Software von hier bereits
@@ -7531,9 +7531,9 @@
<filename>/trunk</filename>: new features, bug fixes, and
so on.</para>
-->
- <para><emphasis>Entwickler übergeben alles Neue an den
+ <para><emphasis>Entwickler übertragen alles Neue an den
Stamm.</emphasis> Tägliche Änderungen werden an
- <filename>/trunk</filename> übergeben: neue Funktionen,
+ <filename>/trunk</filename> übertragen: neue Funktionen,
Fehlerbehebungen usw.</para>
</listitem>
@@ -7694,13 +7694,13 @@
richtige Zeitpunkt zum Anlegen eines Funktions-Zweiges
gekommen ist. Manche Projekte benutzen nie Funktions-Zweige:
jeder darf Änderungen in <filename>/trunk</filename>
- übergeben. Der Vorteil hier ist, dass es einfach ist –
+ übertragen. Der Vorteil hier ist, dass es einfach ist –
niemand benötigt eine Schulung im Verzweigen und
Zusammenführen. Der Nachteil ist, dass der Code oft instabil
oder nicht nutzbar ist. Andere Projekte verwenden
ausschließlich Zweige: Eine Änderung darf
<emphasis>niemals</emphasis> direkt in
- <filename>/trunk</filename> übergeben werden. Selbst die
+ <filename>/trunk</filename> übertragen werden. Selbst die
trivialsten Änderungen werden auf einem kurzlebigen Zweig
durchgeführt, sorgfältig geprüft und in den Stamm
zurückgeführt. Danach wird der Zweig gelöscht. Dieses Vorgehen
@@ -8349,7 +8349,7 @@
<para>Da wir nun einen Lieferanten-Zweig basierend auf
libcomplex 1.0.0 haben, können wir mit den für unsere Zwecke
notwendigen Anpassungen an libcomplex beginnen und sie direkt
- in den erstellten Lieferanten-Zweig übergeben.
+ in den erstellten Lieferanten-Zweig übertragen.
Selbstverständlich können wir anfangen, libcomplex in unseren
eigenen Anwendungen zu verwenden.</para>
@@ -8647,7 +8647,7 @@
basierend auf libcomplex 1.0.0. Wir sind bereit, die für
unsere Zwecke notwendigen Anpassungen an libcomplex
vorzunehmen – indem wir sie direkt in den
- Lieferanten-Zweig übergeben – und unsere angepasste
+ Lieferanten-Zweig übertragen – und unsere angepasste
libcomplex in eigenen Applikationen zu verwenden.</para>
<!--
@@ -9370,7 +9370,7 @@
<!--
<entry>Undo a committed change</entry>
-->
- <entry>Eine übergebene Änderung rückgängig machen</entry>
+ <entry>Eine übertragene Änderung rückgängig machen</entry>
<entry><userinput>svn merge -c -<replaceable>REV</replaceable>
<replaceable>URL</replaceable>; svn commit</userinput></entry>
</row>
=======================================
--- /branches/1.8/de/book/ch05-repository-admin.xml Tue Feb 3 17:18:07
2015 UTC
+++ /branches/1.8/de/book/ch05-repository-admin.xml Tue Feb 24 06:48:19
2015 UTC
@@ -1561,7 +1561,7 @@
-->
<para>FSFS hat auch eine unterschiedliche Charakteristik, was
den Durchsatz anbelangt. Wenn eine große Zahl an Dateien
- übergeben wird, kann FSFS schneller Verzeichniseinträge
+ übertragen wird, kann FSFS schneller Verzeichniseinträge
hinzufügen. Andererseits hat FSFS beim Abschluss einer
Übergabe eine längere Verzögerung während es Aufgaben
durchführt, die das BDB-Backend über die Laufzeit der
@@ -2021,7 +2021,7 @@
Gesamtbild des Projektarchiv-Einsatzes im Auge. Wenn Sie
beispielsweise die Konfiguration des Servers verwenden, um
festzustellen, welche Benutzer Änderungen an Ihr Projektarchiv
- übergeben dürfen, benötigen Sie für diese Zugriffskontrolle
+ übertragen dürfen, benötigen Sie für diese Zugriffskontrolle
nicht das Hook-System.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
@@ -2573,7 +2573,7 @@
<emphasis>keine</emphasis> Übergabe-Transaktion mithilfe
von Hook-Skripten. Trotz der Verlockung, Hook-Skripte zur
automatischen Korrektur von Fehlern, Unzulänglichkeiten
- oder Prozessverletzungen innerhalb der zu übergebenden
+ oder Prozessverletzungen innerhalb der zu übertragenden
Dateien einzusetzen, kann das zu Problemen führen.
Subversion hält bestimmte Projektarchiv-Daten in
client-seitigen Caches vor, und wenn Sie auf diese Art
@@ -2893,7 +2893,7 @@
<command>svnlook</command> wird üblicherweise von
Projektarchiv-Hooks verwendet, um die abzuliefernden Änderungen
zu melden (im Fall des <command>pre-commit</command>-Hooks)
- oder die gerade an das Projektarchiv übergeben wurden (im Fall
+ oder die gerade an das Projektarchiv übertragen wurden (im Fall
des <command>post-commit</command>-hooks). Ein
Projektarchiv-Administrator kann dieses Programm zur Diagnose
benutzen.</para>
@@ -3006,9 +3006,9 @@
removed.</para>
-->
<para>Beachten Sie, dass Sie nur Transaktionen untersuchen
- können, die noch nicht übergeben sind. Die meisten
+ können, die noch nicht übertragen sind. Die meisten
Projektarchive haben keine derartigen Transaktionen, da
- Transaktionen entweder übergeben (in diesem Fall sollten
+ Transaktionen entweder übertragen (in diesem Fall sollten
Sie darauf mit der Option <option>--revision</option>
(<option>-r</option>) zugreifen) oder abgebrochen und
entfernt sind.</para>
@@ -6308,7 +6308,7 @@
<para>Das deckt Änderungen an Revisions-Eigenschaften ab. Nun
müssen
wir sicherstellen, dass nur der Benutzer
<literal>syncuser</literal> neue Revisionen an das Projektarchiv
- übergeben darf. Wir machen das, indem wir ein
+ übertragen darf. Wir machen das, indem wir ein
<filename>start-commit</filename>-Hook-Skript wie das in <xref
linkend="svn.reposadmin.maint.replication.start-commit" />
benutzen.</para>
@@ -6338,7 +6338,7 @@
if [ "$USER" = "syncuser" ]; then exit 0; fi
-echo "Ausschließlich der Benutzer syncuser darf neue Revisionen übergeben"
>&2
+echo "Ausschließlich der Benutzer syncuser darf neue Revisionen
übertragen" >&2
exit 1
</programlisting>
</example>
@@ -7450,7 +7450,7 @@
Berkeley DB. Diese Flexibilität kommt allerdings zu dem Preis,
dass die Wiederherstellung der Daten sehr lange dauern kann
– länger mit jeder neuen Revision, die ins Projektarchiv
- übergeben wird. Wie bei vielen verschiedenen
+ übertragen wird. Wie bei vielen verschiedenen
Sicherungsmethoden werden auch hier Änderungen an
Revisions-Eigenschaften bereits gesicherter Revisionen nicht
berücksichtigt, sofern es sich um eine nicht-überlappende
=======================================
--- /branches/1.8/de/book/ch06-server-configuration.xml Tue Feb 3 17:18:07
2015 UTC
+++ /branches/1.8/de/book/ch06-server-configuration.xml Tue Feb 24 06:48:19
2015 UTC
@@ -3963,7 +3963,7 @@
einfach mit einem Web-Browser geöffnet wird.</para>
</listitem>
<listitem>
- <para>Jeder kann an das Projektarchiv übergeben.</para>
+ <para>Jeder kann an das Projektarchiv übertragen.</para>
</listitem>
</itemizedlist>
@@ -6870,7 +6870,7 @@
#!/bin/sh <!--
# Post-commit script to replicate newly committed revision to slaves
-->
-# Post-Commit-Skript zum Replizieren der neu übergebenen Revision an die
Slaves
+# Post-Commit-Skript zum Replizieren der neu übertragenen Revision an die
Slaves
svnsync sync http://slave1.example.com/svn-proxy-sync \
file:///var/svn/repos > /dev/null 2>&1 &
@@ -7000,7 +7000,7 @@
automatisierten <command>svnsync</command>-Befehle aus
irgendeinem Grund nicht vollständig abgeschlossen wird,
beginnen die Slaves, hinterher zu hinken. Ihre entfernten
- Anwender werden sehen, dass sie Revision 100 übergeben
+ Anwender werden sehen, dass sie Revision 100 übertragen
haben; wenn sie allerdings <command>svn update</command>
aufrufen, wird ihr lokaler Server ihnen mitteilen, dass
Revision 100 noch nicht existiert! Natürlich wird das
@@ -8101,7 +8101,7 @@
Leistungseinbußen. Zur unsichtbaren Kategorie zählt die
Kultur, die Sie erzeugen. In den meisten Fällen, in denen
bestimmte Anwender Änderungen in bestimmte Teile des
- Projektarchivs <emphasis>nicht</emphasis> übergeben sollten,
+ Projektarchivs <emphasis>nicht</emphasis> übertragen sollten,
bedarf diese soziale Übereinkunft keiner technischen
Erzwingung. Teams können manchmal spontan miteinander
arbeiten, jemand könnte jemand anderen aushelfen, indem eine
@@ -8127,7 +8127,7 @@
versehentlich eine Änderung dorthin übergibt, wo sie
eigentlich nicht hin sollte, ist es einfach, die Änderung
rückgängig zu machen. Und sollte ein Anwender mit böser
- Absicht an eine falsche Stelle übergeben, ist es sowieso ein
+ Absicht an eine falsche Stelle übertragen, ist es sowieso ein
sozialen Problem und muss außerhalb von Subversion gelöst
werden.</para>
@@ -8166,7 +8166,7 @@
-->
<para>Als erwägenswertes Beispiel sollten Sie das
Subversion-Projekt betrachten, das stets eine Vorstellung
- davon hatte, wer etwas wohin übergeben darf, dies jedoch immer
+ davon hatte, wer etwas wohin übertragen darf, dies jedoch immer
auf der sozialen Ebene durchsetzte. Dies ist ein passendes
Modell für Vertrauen in einer Gemeinschaft, besonders bei
Open-Source-Projekten. Selbstverständlich existiert manchmal
=======================================
--- /branches/1.8/de/book/ch07-customizing-svn.xml Wed Nov 26 13:14:50 2014
UTC
+++ /branches/1.8/de/book/ch07-customizing-svn.xml Tue Feb 24 06:48:19 2015
UTC
@@ -999,7 +999,7 @@
<para>Diese boolesche Option entspricht der Option
<option>--no-unlock</option> des Befehls <command>svn
commit</command>, die Subversion dazu auffordert,
- Sperren auf gerade übergebene Dateien nicht
+ Sperren auf gerade übertragene Dateien nicht
aufzuheben. Wird diese Laufzeitoption auf
<literal>yes</literal> gesetzt, wird Subversion
niemals automatisch Sperren aufheben, und es Ihnen
@@ -2158,7 +2158,7 @@
in der Kodierung der aktuellen Locale wiedergegeben werden
können. Wenn zum Beispiel Ihre aktuelle Locale
<literal>en_US</literal> ist, aber ein Mitarbeiter einen
- japanischen Dateinamen übergeben hat, bekommen Sie
+ japanischen Dateinamen übertragen hat, bekommen Sie
wahrscheinlich diesen Fehler, wenn Sie bei einem
<command>svn update</command> diese Datei empfangen.</para>
@@ -2211,7 +2211,7 @@
-->
<para>Die offensichtlichste Art und Weise, Daten in Subversion zu
bekommen, ist es, Dateien unter Versionskontrolle zu stellen,
- Änderungen an diesen Dateien zu übergeben usw. Aber neben
+ Änderungen an diesen Dateien zu übertragen usw. Aber neben
versionierten Dateidaten leben auch andere Informationen in
Ihrem Subversion-Projektarchiv. Einige dieser Informationen –
Protokollnachrichten, Kommentare zu Sperren und einige
@@ -2347,7 +2347,7 @@
comments.</para>
-->
<para>Wie beschrieben, können externe Editoren bei allen
- übergebenden Unterbefehlen (wie <command>svn commit</command>
+ übertragenden Unterbefehlen (wie <command>svn commit</command>
oder <command>import</command>, <command>svn mkdir</command>
oder <command>delete</command> wenn ein URL-Ziel angegeben wird
usw.) zur Eingabe von Protokollnachrichten verwendet werden, und
=======================================
--- /branches/1.8/de/book/ch08-embedding-svn.xml Tue Feb 3 17:18:07 2015
UTC
+++ /branches/1.8/de/book/ch08-embedding-svn.xml Tue Feb 24 06:48:19 2015
UTC
@@ -2071,7 +2071,7 @@
* which includes our added directory path.
*/
-->
- /* Die Transaktion übergeben, indem eine neue Revision des
+ /* Die Transaktion übertragen, indem eine neue Revision des
* Dateisystems erzeugt wird, die unseren hinzugefügten
* Verzeichnispfad enthält.
*/
@@ -2161,7 +2161,7 @@
<para>Beachten Sie, dass der Code in <xref
linkend="svn.developer.layerlib.repos.ex-1" /> die Transaktion
ebenso einfach mit <function>svn_fs_commit_txn()</function>
- hätte übergeben können. Allerdings weiß die Dateisystem-API
+ hätte übertragen können. Allerdings weiß die Dateisystem-API
nichts über den Hook-Mechanismus der Projektarchiv-Bibliothek.
Falls Sie möchten, dass Ihr Subversion-Projektarchiv bei jeder
Transaktionsübergabe eine Nicht-Subversion-Aufgabe ausführt
=======================================
--- /branches/1.8/de/book/ref-svn.xml Tue Feb 3 17:18:07 2015 UTC
+++ /branches/1.8/de/book/ref-svn.xml Tue Feb 24 06:48:19 2015 UTC
@@ -1128,7 +1128,7 @@
-->
<para>Teilt Subversion mit, Dateien nicht automatisch zu
entsperren. (Das Standardverhalten nach der Übergabe ist
- es, alle Dateien, die übergeben wurden, zu entsperren.)
+ es, alle Dateien, die übertragen wurden, zu entsperren.)
Siehe <xref linkend="svn.advanced.locking"/> für
weitergehende Informationen.</para>
</listitem>
@@ -2442,7 +2442,7 @@
commit only files in that changelist:</para>
-->
<para>Ändern Sie drei Dateien, fügen Sie sie einer
- Änderungsliste hinzu und übergeben dann nur die Dateien
+ Änderungsliste hinzu und übertragen dann nur die Dateien
auf dieser Änderungsliste:</para>
<informalexample>
@@ -2486,7 +2486,7 @@
committed.</para>
-->
<para>Beachten Sie, dass im vorigen Beispiel nur die Dateien
- der Änderungsliste <literal>issue1729</literal> übergeben
+ der Änderungsliste <literal>issue1729</literal> übertragen
wurden.
</para>
@@ -2802,7 +2802,7 @@
<para>Wie auch bei anderen Arbeitskopien haben Sie die
üblichen Möglichkeiten zur Auswahl: die lokalen
<quote>Änderungen</quote> teilweise oder vollständig
- rückgängig machen, sie übergeben oder mit Änderungen in
+ rückgängig machen, sie übertragen oder mit Änderungen in
Ihrer Arbeitskopie fortfahren.</para>
<!--
@@ -3003,7 +3003,7 @@
<refpurpose>Send changes from your working copy to the
repository.</refpurpose>
-->
<refpurpose>Änderungen aus der Arbeitskopie an das
- Projektarchiv übergeben.</refpurpose>
+ Projektarchiv übertragen.</refpurpose>
</refnamediv>
<refsynopsisdiv>
@@ -3029,7 +3029,7 @@
linkend="svn.advanced.confarea.opts.config"/>.</para>
-->
<para>Änderungen aus der Arbeitskopie an das Projektarchiv
- übergeben. Falls Sie keine Protokollnachricht, mit einer
+ übertragen. Falls Sie keine Protokollnachricht, mit einer
der Optionen <option>--file</option> (<option>-F</option>)
oder <option>--message</option> (<option>-m</option>),
angeben, startet <command>svn</command> Ihren Editor zum
@@ -3046,7 +3046,7 @@
<para><command>svn commit</command> verschickt alle
gefundenen Sperrmarken und gibt Sperren auf alle mit
<replaceable>PATH</replaceable> angegebenen Pfade frei,
- die (rekursiv) übergeben werden, sofern die Option
+ die (rekursiv) übertragen werden, sofern die Option
<option>--no-unlock</option> nicht angegeben ist.</para>
<tip>
@@ -3062,7 +3062,7 @@
<para>Falls Sie eine Übergabe einleiten und Subversion
Ihren Editor zum Verfassen einer Protokollnachricht
startet, können Sie immer noch abbrechen, ohne Ihre
- Änderungen zu übergeben. Wenn Sie die Übergabe abbrechen
+ Änderungen zu übertragen. Wenn Sie die Übergabe abbrechen
wollen, beenden Sie einfach Ihren Editor, ohne die
Protokollnachricht zu sichern; dann wird Subversion Sie
fragen, ob Sie die Übergabe abbrechen, ohne
@@ -3183,7 +3183,7 @@
<!--
<para>To commit a file scheduled for deletion:</para>
-->
- <para>Eine zur Löschung vorgemerkte Datei übergeben:</para>
+ <para>Eine zur Löschung vorgemerkte Datei übertragen:</para>
<informalexample>
<screen>
@@ -3281,7 +3281,7 @@
<para>Immediately commit a copy of WC to URL.</para>
-->
<para>Eine Kopie aus der AK direkt an den URL
- übergeben.</para>
+ übertragen.</para>
</listitem>
</varlistentry>
@@ -3578,7 +3578,7 @@
-->
<para>Die durch <replaceable>PATH</replaceable> angegebenen
Objekte werden zur Löschung bei der nächsten Übergabe
- vorgemerkt. Dateien (und nicht übergebene Verzeichnisse)
+ vorgemerkt. Dateien (und nicht übertragene Verzeichnisse)
werden sofort aus der Arbeitskopie entfernt, sofern nicht
die Option <option>--keep-local</option> angegeben ist.
Der Befehl entfernt keine unversionierten oder geänderten
@@ -3593,7 +3593,7 @@
-->
<para>Werden Objekte durch einen URL bestimmt, werden sie
durch eine sofortige Übergabe aus dem Projektarchiv
- entfernt. Mehrere URLs werden atomar übergeben (alle oder
+ entfernt. Mehrere URLs werden atomar übertragen (alle oder
keine).</para>
</refsect1>
@@ -3717,7 +3717,7 @@
dass auch die Zieldatei entfernt wird, die für eine
versionierte Löschung vorgemerkt war. Das ist in dem Fall
nützlich, falls Sie feststellen, dass Sie versehentlich
- eine hinzugefügte Datei übergeben haben, die Sie zwar in
+ eine hinzugefügte Datei übertragen haben, die Sie zwar in
Ihrer Arbeitskopie benötigen, jedoch nicht unter
Versionskontrolle stehen soll.</para>
@@ -3753,7 +3753,7 @@
<para>Das Verhalten der Option <option>--keep-local</option>
wirkt sich nicht auf andere Arbeitskopien aus, die von Ihnen
zur Löschung vorgemerkte Objekte enthalten. Wenn Sie die
- Löschung dieser Objekte übergeben, verbleiben sie in Ihrer
+ Löschung dieser Objekte übertragen, verbleiben sie in Ihrer
Arbeitskopie, werden aber bei der Aktualisierung anderer
Arbeitskopien in denen sie enthalten sind gelöscht.</para>
</note>
@@ -5239,7 +5239,7 @@
-->
<refpurpose>Pfade der Arbeitskopie oder URLs im
Projektarchiv sperren, damit kein anderer Benutzer
- Änderungen daran übergeben kann.</refpurpose>
+ Änderungen daran übertragen kann.</refpurpose>
</refnamediv>
<refsynopsisdiv>
@@ -6540,7 +6540,7 @@
Arbeitskopie vorgemerkt. Ein durch einen URL bezeichnetes
Verzeichnis wird durch eine unmittelbare Übergabe im
Projektarchiv erzeugt. Mehrere Verzeichnis-URLs werden atomar
- übergeben. In beiden Fällen müssen Zwischenverzeichnisse
+ übertragen. In beiden Fällen müssen Zwischenverzeichnisse
bereits existieren, falls die Option
<option>--parents</option> nicht angegeben wird.</para>
</refsect1>
@@ -6817,7 +6817,7 @@
<!--
Committed revision 27.
-->
-Revision 27 übergeben.
+Revision 27 übertragen.
</screen>
</informalexample>
@@ -8527,7 +8527,7 @@
Konflikt stehende Objekt mit der (interaktiv oder über das
Optionsargument von <option>--accept</option>) angegebenen
Version und entfernt dann Konfliktdateien. Das erlaubt es,
- <replaceable>PATH</replaceable> erneut zu übergeben –
+ <replaceable>PATH</replaceable> erneut zu übertragen –
d.h., Subversion wird mitgeteilt, dass die Konflikte
<quote>aufgelöst</quote> wurden.</para>
<!--
@@ -8674,7 +8674,7 @@
Routine löst Konfliktmarken nicht semantisch auf sondern
entfernt lediglich konfliktbezogene Dateiartefakte und
erlaubt es, <replaceable>PATH</replaceable> erneut zu
- übergeben, d.h., Subversion wird mitgeteilt, dass die
+ übertragen, d.h., Subversion wird mitgeteilt, dass die
Konflikte <quote>aufgelöst</quote> wurden. Siehe <xref
linkend="svn.tour.cycle.resolve"/> für eine tiefgehende
Erörterung der Konfliktauflösung.</para> </refsect1>
@@ -8918,11 +8918,11 @@
-->
<para><command>svn revert</command> ist von Natur aus
gefährlich, da sein einziger Zweck das Beseitigen von
- Daten ist – nämlich Ihre noch nicht übergebenen
+ Daten ist – nämlich Ihre noch nicht übertragenen
Änderungen. Sobald Sie irgendetwas rückgängig gemacht
haben, bietet Ihnen Subversion <emphasis>keine
Möglichkeit</emphasis>, wieder an die noch nicht
- übergebenen Änderungen heranzukommen.</para>
+ übertragenen Änderungen heranzukommen.</para>
<!--
<para>If you provide no targets to <command>svn
@@ -9253,7 +9253,7 @@
<!--
<para>No history scheduled with commit.</para>
-->
- <para>Geschichte soll nicht übergeben werden.</para>
+ <para>Geschichte soll nicht übertragen werden.</para>
</listitem>
</varlistentry>
@@ -9263,7 +9263,7 @@
<!--
<para>History scheduled with commit.</para>
-->
- <para>Geschichte soll übergeben werden.</para>
+ <para>Geschichte soll übertragen werden.</para>
</listitem>
</varlistentry>
@@ -9499,7 +9499,7 @@
-->
<para>Falls die Option <option>--verbose</option>
(<option>-v</option>) angegeben wird, folgt die letzte
- übergebene Revision und der Autor derselben.</para>
+ übertragene Revision und der Autor derselben.</para>
<!--
<para>The working copy path is always the final field, so
@@ -9916,7 +9916,7 @@
vergessen, dass Sie das getan haben, so dass es damit
endet, dass Sie versehentlich Änderungen an die
umgeschalteten und originalen Teile Ihres Baums
- übergeben.</para>
+ übertragen.</para>
</tip>
</refsect1>
=======================================
--- /branches/1.8/de/book/ref-svnmucc.xml Tue Nov 25 15:14:00 2014 UTC
+++ /branches/1.8/de/book/ref-svnmucc.xml Tue Feb 24 06:48:19 2015 UTC
@@ -31,7 +31,7 @@
umfangreicher als die vom Subversion-Kommandozeilen-Client
bereitgestellte. So ist beispielsweise
<command>svnmucc</command> nicht darauf beschränkt, lediglich
- einen einzigen Änderungstyp in einer Übertragung zu übergeben.
+ einen einzigen Änderungstyp in einer Übertragung zu behandeln.
Es vermag ebenso Änderungen an Dateiinhalten und versionierten
Eigenschaften ohne Arbeitskopie vornehmen, was momentan von
<command>svn</command> nicht unterstützt wird.</para>
More information about the svnbook-dev
mailing list