[svnbook commit] r3295 - trunk/src/de/book
khmarbaise
noreply at red-bean.com
Mon Sep 8 14:01:12 CDT 2008
Author: khmarbaise
Date: Mon Sep 8 14:01:12 2008
New Revision: 3295
Log:
* src/de/book/ch01-fundamental-concepts.xml
- Enhanced german translation of the section
"The Lock-Modify-Unlock Solution"
Modified:
trunk/src/de/book/ch01-fundamental-concepts.xml
Modified: trunk/src/de/book/ch01-fundamental-concepts.xml
==============================================================================
--- trunk/src/de/book/ch01-fundamental-concepts.xml (original)
+++ trunk/src/de/book/ch01-fundamental-concepts.xml Mon Sep 8 14:01:12 2008
@@ -171,27 +171,24 @@
with. Harry's work is still effectively lost—or at
least missing from the latest version of the file—and
probably by accident. This is definitely a situation we want
- to avoid!</para> -->
- <para>Beachten Sie das dargestellte Szenario Consider<xref
- linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.
- Nehmen wir an wir haben zwei Kollegen, Harry und Sally.
- Sie haben sich beide entschieden die gleiche Datei zur gleichen
- Zeit zu bearbeiten. Wenn Harry seine Ãnderungen im Repository
- zuerst speichert ist es möglich, dass einige Augenblicke
- später, Sally unbeabsichtigt mit Ihrer eigenen Version der
- Datei überschreibt. Während Harry's Version der Datei nicht
- für immer verloren ist (weil das System jegliche Ãnderung
- aufzeichnet) jede Ãnderung die Harry gemacht hat
-
- overwrite them with her own new version of the file. While
- Harry's version of the file won't be lost forever (because the
- system remembers every change), any changes Harry made
- <emphasis>won't</emphasis> be present in Sally's newer version
- of the file, because she never saw Harry's changes to begin
- with. Harry's work is still effectively lost—or at
- least missing from the latest version of the file—and
- probably by accident. This is definitely a situation we want
- to avoid!</para>
+ to avoid!</para> -->
+
+ <para>Stellen Sie sich einmal folgendes <xref
+ linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>Szenario vor:
+ Zwei Kollegen, Harry und Sally haben sich entschieden,
+ die gleiche Datei zur gleichen Zeit zu bearbeiten.
+ Harry speichert seine Änderungen zuerst im Repository,
+ es ist aber möglich, dass Sally nur einige Augenblicke
+ später mit ihrer Datei seine überschreibt.
+ Harrys Änderungen der Datei sind zwar nicht für immer
+ verloren (da das System jede Änderung aufzeichnet), aber
+ alle seine Änderungen sind in Sallys später gespeicherter
+ Version der Datei nicht vorhanden, da Sally diese Änderungen
+ noch gar nicht kannte. Das heißt, dass Harrys Arbeit
+ doch verloren ist zumindest in der neuesten Version der
+ Datei und das nur durch einen Zufall.
+ Eine solche Situation wollen wir auf alle Fälle vermeiden.
+ </para>
<figure id="svn.basic.vsn-models.problem-sharing.dia-1">
<title>The problem to avoid</title>
@@ -204,6 +201,7 @@
<sect2 id="svn.basic.vsn-models.lock-unlock">
<title>The Lock-Modify-Unlock Solution</title>
+ <!--
<para>Many version control systems use a
<firstterm>lock-modify-unlock</firstterm> model to address the
problem of many authors clobbering each other's work. In this
@@ -218,17 +216,36 @@
editing the file. <xref
linkend="svn.basic.vsn-models.lock-unlock.dia-1"/>
demonstrates this simple solution.</para>
+ -->
+
+ <para>Viele Versionskontrollsysteme verwenden ein
+ <firstterm>Sperren - Ändern - Entsperren</firstterm>-Modell
+ um zu verhindern, dass verschiedene Autoren sich gegenseitig die
+ Änderungen löschen. Bei diesem Modell erlaubt das Repository nur
+ jeweils einem Programmierer den Zugriff auf eine Datei.
+ Harry müsste also die Datei sperren, ehe er anfängt, seine
+ Änderungen einzugeben. Wenn Harry die Datei gesperrt hat,
+ kann Sally sie nicht ebenfalls sperren und daher auch nichts
+ ändern. Sie kann die Datei in der Zeit nur lesen und darauf
+ warten, dass Harry mit seiner Arbeit fertig ist und die Datei
+ entsperrt. <xref linkend="svn.basic.vsn-models.lock-unlock.dia-1"/></para>
<figure id="svn.basic.vsn-models.lock-unlock.dia-1">
- <title>The lock-modify-unlock solution</title>
+ <title>Die Sperren - Ändern - Entsperren - Lösung veranschaulicht diese einfache Möglichkeit</title>
<graphic fileref="images/ch02dia3.png"/>
</figure>
+ <!--
<para>The problem with the lock-modify-unlock model is that it's
a bit restrictive and often becomes a roadblock for
- users:</para>
+ users:</para>
+ -->
+
+ <para>Das Problem bei einem Sperren - Ändern - Entsperren - Modell liegt
+ in seinen Beschränkungen, die oft zu schier unüberwindlichen Hindernissen führen können.</para>
<itemizedlist>
+ <!--
<listitem>
<para><emphasis>Locking may cause administrative
problems.</emphasis>
@@ -240,7 +257,19 @@
The situation ends up causing a lot of unnecessary delay
and wasted time.</para>
</listitem>
+ -->
+ <listitem>
+ <para><emphasis>Das Sperren kann zu administrativen Problemen führen.</emphasis>
+ Vielleicht sperrt Harry einen File und vergisst dann,
+ ihn zu entsperren. In der Zwischenzeit sind Sally,
+ die ebenfalls Änderungen an diesem File durchführen will,
+ die Hände gebunden. Und dann geht Harry in Urlaub.
+ Nun muss Sally sich an einen Administrator wenden
+ um den File entsperrt zu bekommen. Das Ergebnis
+ sind unnötige Verzögerungen und vergeudete Zeit.</para>
+ </listitem>
+ <!--
<listitem>
<para><emphasis>Locking may cause unnecessary
serialization.</emphasis>
@@ -253,7 +282,21 @@
There's no need for them to take turns in this
situation.</para>
</listitem>
-
+ -->
+ <listitem>
+ <para><emphasis>Das Sperren kann zu einer unnötigen Serialisierung führen
+ .</emphasis>
+
+ Was ist, wenn Harry z. B. den Anfang eines Textfiles
+ bearbeiten will, während Sally einfach nur das Ende
+ ändern möchte? Diese Änderungen würden sich überhaupt
+ nicht gegenseitig beeinflussen und könnten problemlos
+ gleichzeitig durchgeführt werden, vorausgesetzt, sie
+ würden anschließend vernünftig zusammengefasst.
+ Es gibt in dieser Situation keinen Grund, der Reihe
+ nach zu arbeiten.</para>
+ </listitem>
+ <!--
<listitem>
<para><emphasis>Locking may create a false sense of
security.</emphasis>
@@ -270,6 +313,27 @@
their incompatible changes early on. Locking often
becomes a substitute for real communication.</para>
</listitem>
+ -->
+ <listitem>
+ <para><emphasis>Das Sperren kann zu einem falschen Gefühl von Sicherheit führen
+ .</emphasis>
+
+ Angenommen Harry sperrt und bearbeitet File A,
+ während Sally gleichzeitig Änderungen an File B
+ durchführt. Was ist, wenn A und B voneinander abhängig
+ sind und die jeweiligen Änderungen nicht kompatibel sind?
+ Plötzlich funktioniert das Zusammenspiel zwischen A
+ und B nicht mehr. Das System des Sperrens hat dieses
+ Problem nicht verhindert doch hat es fälschlicherweise
+ zu einem Gefühl der Sicherheit geführt. Es ist leicht,
+ sich vorzustellen, dass Harry und Sally der Meinung
+ waren, dass jeder von ihnen eine eigenständige,
+ voneinander unabhängige Änderung durchgeführt hat
+ und dass das Sperren dazu geführt hat, dass sie ihre
+ inkompatiblen Änderungen nicht vorher miteinander
+ besprochen haben. Sperren ist oft ein Ersatz für
+ echte Kommunikation.</para>
+ </listitem>
</itemizedlist>
</sect2>
More information about the svnbook-dev
mailing list