[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