[svnbook] r4736 committed - Translation: Using Branches (intro)
svnbook at googlecode.com
svnbook at googlecode.com
Sat Mar 22 05:31:40 CDT 2014
Revision: 4736
Author: jmfelderhoff at gmx.eu
Date: Sat Mar 22 10:31:27 2014 UTC
Log: Translation: Using Branches (intro)
http://code.google.com/p/svnbook/source/detail?r=4736
Modified:
/branches/1.7/de/book/ch04-branching-and-merging.xml
=======================================
--- /branches/1.7/de/book/ch04-branching-and-merging.xml Fri Mar 21
22:45:10 2014 UTC
+++ /branches/1.7/de/book/ch04-branching-and-merging.xml Sat Mar 22
10:31:27 2014 UTC
@@ -166,7 +166,7 @@
nach.</para>
<!--
- <para>For this chapter, we'll go back to the same example from
+ <para>Let's revisit the example from
<xref linkend="svn.basic"/>. Remember that you and your
collaborator, Sally, are sharing a repository that contains two
projects, <filename>paint</filename> and
@@ -176,13 +176,13 @@
<filename>trunk</filename> and <filename>branches</filename>.
The reason for this will soon become clear.</para>
-->
- <para>Für dieses Kapitel verwenden wir das Beispiel aus <xref
- linkend="svn.basic"/>. Erinnern Sie sich, dass Sie und Ihre
- Mitarbeiterin Sally sich ein Projektarchiv teilen, das zwei
- Projekte beinhaltet: <filename>paint</filename> und
- <filename>calc</filename>. Beachten Sie, dass in <xref
- linkend="svn.branchmerge.using.dia-1"/> dieses Mal jedoch jedes
- Projektverzeichnis Unterverzeichnisse namens
+ <para>Lassen Sie uns noch einmal auf das Beispiel aus
+ <xref linkend="svn.basic"/> zurückkommen. Erinnern Sie sich,
+ dass Sie und Ihre Mitarbeiterin Sally sich ein Projektarchiv
+ teilen, das zwei Projekte beinhaltet: <filename>paint</filename>
+ und <filename>calc</filename>. Beachten Sie, dass in <xref
+ linkend="svn.branchmerge.using.dia-1"/> dieses Mal jedoch
+ jedes Projektverzeichnis Unterverzeichnisse namens
<filename>trunk</filename> und <filename>branches</filename>
beinhaltet. Der Grund hierfür wird bald klar sein.</para>
@@ -237,75 +237,70 @@
bringen.</para>
<!--
- <para>One strategy is to crawl into a hole: you and Sally can stop
- sharing information for a week or two. That is, start gutting
- and reorganizing all the files in your working copy, but don't
- commit or update until you're completely finished with the task.
- There are a number of problems with this, though. First, it's
- not very safe. Most people like to save their work to the
- repository frequently, should something bad accidentally happen
- to their working copy. Second, it's not very flexible. If you
- do your work on different computers (perhaps you have a working
- copy of <filename>/calc/trunk</filename> on two different
- machines), you'll need to manually copy your changes back and
- forth or just do all the work on a single computer. By that
- same token, it's difficult to share your changes in progress
- with anyone else. A common software development <quote>best
- practice</quote> is to allow your peers to review your work as
- you go. If nobody sees your intermediate commits, you lose
- potential feedback and may end up going down the wrong path for
- weeks before another person on your team notices. Finally, when
- you're finished with all your changes, you might find it very
- difficult to remerge your final work with the rest of the
- company's main body of code. Sally (or others) may have made
- many other changes in the repository that are difficult to
- incorporate into your working copy—especially if you
- run <command>svn update</command> after weeks of
- isolation.</para>
+ <para>One strategy is to crawl into a hole: you can stop sharing
+ information for a week or two, gutting and reorganizing all the
+ files in your private working copy but not committing or
+ updating until you're completely finished with your task. There
+ are a number of problems with this, though. First, it's not
+ very safe. Should something bad happen to your working copy or
+ computer, you risk losing all your changes. Second, it's not
+ very flexible. Unless you manually replicate your changes
+ across different working copies or computers, you're stuck trying
+ to make your changes in a single working copy. Similarly, it's
+ difficult to share your work-in-progress with anyone else. A
+ common software development <quote>best practice</quote> is to
+ allow your peers to review your work as you go. If nobody sees
+ your intermediate commits, you lose potential feedback and may
+ end up going down the wrong path for weeks before another person
+ on your team notices. Finally, when you're finished with all
+ your changes, you might find it very difficult to merge your
+ completed work with the rest of the company's main body of code.
+ Sally (or others) may have made many other changes in the
+ repository that are difficult to incorporate into your working
+ copy when you eventually run <command>svn update</command> after
+ weeks of isolation.</para>
-->
- <para>Eine Strategie ist, sich in ein Loch zu verkriechen: Sie und
- Sally können für eine Woche oder zwei den Informationsaustausch
- einstellen. Das heißt, Sie fangen damit an, die Dateien Ihrer
- Arbeitskopie auszuräumen und umzuorganisieren, ohne Änderungen
- zu übergeben 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. Viele
- Leute möchten Ihre Arbeit regelmäßig ins Projektarchiv sichern, für
- den Fall, dass etwas Schlimmes mit der Arbeitskopie passieren
- könnte. Zweitens ist das nicht sehr flexibel. Falls Sie Ihre
- Arbeit an mehreren Rechnern verrichten (vielleicht haben Sie
- eine Arbeitskopie von <filename>/calc/trunk</filename> auf zwei
- unterschiedlichen Maschinen), müssten Sie entweder alle
- Änderungen manuell hin und her kopieren oder die gesamte Arbeit
- an nur einem Rechner erledigen. Ebenso schwierig wäre es, Ihre
- Änderungen mit anderen zu teilen. Eine weit verbreitete
- <quote>beste Vorgehensweise</quote> ist es, Ihren Mitarbeitern
- zu erlauben, während Sie mit Ihrer Arbeit fortfahren, Ihre
- bisherigen Ergebnisse zu überprüfen. Wenn niemand Ihre
- unmittelbaren Änderungen sieht, haben Sie keine möglichen
- Rückmeldungen und es könnte sein, dass Sie für Wochen einen
- falschen Weg einschlagen, bevor es jemand aus Ihrem Team
- bemerkt. Schließlich könnte es am Ende, wenn Sie mit Ihren
- Ä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
- schwer in Ihre Arbeitskopie einarbeiten ließen –
- besonders, falls Sie <command>svn update</command> nach Wochen
- der Isolierung ausführen.</para>
+ <para>Eine Strategie ist, 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
+ 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
+ oder Ihrem Rechner etwas Schlimmes zustoßen sollte, riskieten
+ Sie, alle Ihre Änderungen zu verlieren. Zweitens ist es nicht
+ sehr flexibel. Falls Sie Ihre Änderungen nicht manuell über
+ mehrere Arbeitskopien oder Rechner abgleichen, müssen Sie Ihre
+ Änderungen in einer einzigen Arbeitskopie vornehmen. Ebenso
+ schwierig wäre es, Ihre Änderungen mit anderen zu teilen. Eine
+ weit verbreitete <quote>beste Vorgehensweise</quote> ist es,
+ Ihren Mitarbeitern zu erlauben, Ihre bisherigen Ergebnisse zu
+ überprüfen, während Sie mit Ihrer Arbeit fortfahren. Wenn
+ niemand Ihre unmittelbaren Änderungen sieht, haben Sie keine
+ möglichen Rückmeldungen und es könnte sein, dass Sie für Wochen
+ einen falschen Weg einschlagen, bevor es jemand aus Ihrem Team
+ bemerkt. Schließlich könnte es am Ende sehr schwierig sein, Ihr
+ Arbeitsergebnis wieder mit dem Hauptteil der Quelltexte Ihrer
+ Firma zusammenzuführen, wenn Sie mit Ihren Änderungen fertig
+ sind. Sally (und andere) hätten viele andere Änderungen ins
+ Projektarchiv übergeben 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>
<!--
<para>The better solution is to create your own branch, or line of
development, in the repository. This allows you to save your
- half-broken work frequently without interfering with others, yet
- you can still selectively share information with your
- collaborators. You'll see exactly how this works as we go.
- </para>
+ not-yet-completed work frequently without interfering with
+ others' changes and while still selectively sharing information
+ with your collaborators. You'll see exactly how this works as
+ we continue.</para>
-->
- <para>Die bessere Lösung ist, Ihren eigenen Zweig oder Ihre eigene
- Entwicklungslinie im Projektarchiv zu erzeugen. Dies erlaubt Ihnen,
- Ihre halbfertigen Arbeitsergebnisse regelmäßig zu sichern, ohne
- andere zu stören; dennoch können Sie selektiv Informationen mit
+ <para>Die bessere Lösung ist es, Ihren eigenen Zweig oder Ihre
+ eigene Entwicklungslinie im Projektarchiv zu erzeugen. Dies
+ erlaubt Ihnen, Ihre unvollständigen Arbeitsergebnisse regelmäßig
+ zu sichern, ohne die Änderungen anderer zu stören; dennoch
+ können Sie selektiv Informationen mit
Ihren Kollegen teilen. Im Weiteren werden Sie sehen, wie das
funktioniert.</para>
More information about the svnbook-dev
mailing list