[svnbook commit] r3403 - trunk/src/de/book

jmfelderhoff noreply at red-bean.com
Mon Jan 26 15:08:16 CST 2009


Author: jmfelderhoff
Date: Mon Jan 26 15:08:16 2009
New Revision: 3403

Log:
* trunk/src/de/book/ch05-repository-admin.xml
  - Fixes #200 (cf. http://www.svnbook.de/report/6).


Modified:
   trunk/src/de/book/ch05-repository-admin.xml

Modified: trunk/src/de/book/ch05-repository-admin.xml
==============================================================================
--- trunk/src/de/book/ch05-repository-admin.xml	(original)
+++ trunk/src/de/book/ch05-repository-admin.xml	Mon Jan 26 15:08:16 2009
@@ -330,8 +330,12 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.reposadmin.projects.chooselayout">
+<!--
       <title>Planning Your Repository Organization</title>
+-->
+      <title>Planung der Organisation Ihres Repositorys</title>
 
+<!--
       <para>While Subversion allows you to move around versioned files
         and directories without any loss of information, and even
         provides ways of moving whole sets of versioned history from
@@ -343,14 +347,37 @@
         conscientiously <quote>laying out</quote> your repository or
         repositories and their versioned contents ahead of time, you
         can prevent many future headaches.</para>
+-->
+      <para>Obwohl Subversion Ihnen erlaubt, versionierte Dateien und
+        Ordner ohne Informationsverlust hin und her zu verschieben und
+        sogar Methoden anbietet, um versionierte Geschichte von einem
+        Repository in ein anderes zu verschieben, kann das ziemlich
+        den Arbeitsablauf derjenigen stören, die oft auf das
+        Repository zugreifen und gewisse Dinge an bestimmten Orten
+        erwarten. Bevor Sie ein neues Repository erstellen, sollten
+        Sie also versuchen, ein wenig in die Zukunft zu schauen;
+        planen Sie weitsichtig, bevor Sie Ihre Daten unter
+        Versionskontrolle stellen. Durch die vorzeitige gewissenhafte
+        <quote>Anlage</quote> Ihres Repositorys oder mehrerer
+        Repositorys können Sie viel künftigen Kopfschmerz
+        vermeiden.</para>
 
+<!--
       <para>Let's assume that as repository administrator, you will be
         responsible for supporting the version control system for
         several projects.  Your first decision is whether to use a
         single repository for multiple projects, or to give each
         project its own repository, or some compromise of these
         two.</para>
+-->
+      <para>Nehmen wir an, Sie seien als Repository-Administrator für
+        die Versionskontrollsysteme mehrerer Projekte zuständig. Ihre
+        erste Entscheidung ist, ob Sie ein einzelnes Repository für
+        mehrere Projekte verwenden, jedem Projekt sein eigenes
+        Repository geben oder einen Kompromiss aus diesen beiden
+        Lösungen  haben wollen.</para>
 
+<!--
       <para>There are benefits to using a single repository for
         multiple projects, most obviously the lack of duplicated
         maintenance.  A single repository means that there is one set
@@ -359,7 +386,18 @@
         version, and so on.  Also, you can move data between projects
         easily, without losing any historical versioning
         information.</para>
+-->
+      <para>Ein einzelnes Repository für mehrere Projekte zu
+        verwenden, hat einige Vorteile, am offensichtlichsten ist der
+        vermiedene doppelte Verwaltungsaufwand. Ein einzelnes
+        Repository bedeutet, dass es nur einen Satz Hook-Programme,
+        ein Ding zum routinemäßigen Sichern, ein Ding für einen Auszug
+        und zum anschließenden Laden nach einer inkompatiblen neuen
+        Version von Subversion gibt usw. Sie können Daten auch einfach
+        zwischen Projekten verschieben, ohne historische
+        Versionierungsinformationen zu verlieren.</para>
 
+<!--
       <para>The downside of using a single repository is that
         different projects may have different requirements in terms of
         the repository event triggers, such as needing to send commit
@@ -385,7 +423,37 @@
             projects and repositories.</para>
         </footnote>
       </para>
+-->
+      <para>Der Nachteil bei der Verwendung eines einzelnen
+        Repositorys ist, dass unterschiedliche Projekte auch
+        unterschiedliche Anforderungen hinsichtlich der
+        Repository-Ereignis-Trigger haben, wie etwa
+        Benachrichtigungs-E-Mails bei Commits an unterschiedliche
+        Verteiler, oder unterschiedliche Definitionen dazu, was eine
+        berechtigte Übergabe ist und was nicht. Das sind natürlich
+        keine unüberwindbaren Probleme – es bedeutet nur, dass
+        all Ihre Hook-Skripte die Struktur Ihres Repositorys beachten
+        müssen, anstatt davon auszugehen, dass das gesamte Repository
+        von einer einzelnen Gruppe zugeordnet ist. Beachten Sie auch,
+        dass Subversion Versionsnummern verwendet, die global für das
+        gesamte Repository gelten. Obwohl diese Nummern keine
+        Zauberkräfte haben, mögen manche Zeitgenossen es trotzdem
+        nicht, dass, obwohl in letzter Zeit keine Änderungen in ihrem
+        Projekt durchgeführt worden sind, die jüngste Versionsnummer
+        im Repository ständig höher wird, weil andere Projekte fleißig
+        neue Revisionen hinzufügen.
+        <footnote>
+          <para>Ob es an Ignoranz oder an schlecht überlegten
+            Konzepten zur Erstellung berechtigter Metriken für die
+            Software-Entwicklung liegt,  ist es dumm, Angst vor
+            globalen Revisionsnummern zu haben, und es ist deshalb
+            <emphasis>kein</emphasis> Kriterium, das Sie heranziehen
+            sollten, wenn Sie abwägen, wie Sie Ihre Projekte und
+            Repositorys anlegen wollen.</para>
+        </footnote>
+      </para>
 
+<!--
       <para>A middle-ground approach can be taken, too.  For example,
         projects can be grouped by how well they relate to each other.
         You might have a few repositories with a handful of projects
@@ -394,7 +462,19 @@
         added to the repository, at least the developers know that
         those new revisions are at least remotely related to everyone
         who uses that repository.</para>
+-->
+      <para>Es kann auch eine Lösung in der Mitte gewählt werden.
+        Beispielsweise können Projekte danach geordnet werden, wie
+        stark sie miteinander verbunden sind. Sie könnten ein paar
+        Repositorys haben, die jeweils eine handvoll Projekte
+        beherbergen. Auf diese Art können Projekte, die wahrscheinlich
+        gemeinsame Daten verwenden wollen, dies auch einfach
+        bewerkstelligen, und wenn dem Repository neue Versionen
+        hinzugefügt werden, wissen die Entwickler wenigstens, dass
+        diese neuen Revisionen zumindest entfernt eine Beziehung zu
+        jedem Benutzer dieses Repositorys haben.</para>
 
+<!--
       <para>After deciding how to organize your projects with respect
         to repositories, you'll probably want to think about directory
         hierarchies within the repositories themselves.  Because
@@ -418,8 +498,36 @@
             to as <quote>the TTB directories.</quote></para>
         </footnote>
         </para>
+-->
+      <para>Nachdem Sie entschieden haben, wie Sie Ihre Projekte in
+        Repositorys aufteilen, möchten Sie sich nun vielleicht
+        Gedanken darüber machen, welche Verzeichnishierarchien Sie im
+        Repository anlegen wollen. Da Subversion zum Verzweigen und
+        Taggen reguläre Verzeichniskopien verwendet (siehe <xref
+        linkend="svn.branchmerge"/>), empfiehlt die
+        Subversion-Gemeinschaft, dass Sie einen Ort im Repository für
+        jedes <firstterm>Projekt-Wurzelverzeichnis</firstterm> wählen
+        – das oberste Verzeichnis, das Daten für Ihr Projekt
+        enthält – und hierunter dann drei Unterverzeichnisse
+        anlegen: <filename>trunk</filename>, das Verzeichnis, in dem
+        die Hauptentwicklung stattfindet,
+        <filename>branches</filename>, zur Aufnahme verschiedener
+        Zweige der Hauptentwicklungslinie und
+        <filename>tags</filename>, als Sammlung von Momentaufnahmen
+        des Verzeichnisbaums, die erzeugt, vielleicht gelöscht, jedoch
+        nie verändert werden
+        <footnote>
+          <para>Das Trio <filename>trunk</filename>,
+          <filename>tags</filename>, and <filename>branches</filename>
+          wird manchmal als <quote>die TTB-Verzeichnisse</quote>
+          bezeichnet.</para>
+        </footnote>.
+        </para>
 
+<!--
       <para>For example, your repository might look like this:</para>
+-->
+      <para>Ihr Repository könnte z.B. so aussehen:</para>
 
       <screen>
 /
@@ -438,6 +546,7 @@
    …
 </screen>
 
+<!--
       <para>Note that it doesn't matter where in your repository each
         project root is.  If you have only one project per repository,
         the logical place to put each project root is at the root of
@@ -447,6 +556,17 @@
         shared code in the same subdirectory, or maybe just grouping
         them alphabetically.  Such an arrangement might look
         like this:</para>
+-->
+      <para>Beachten Sie, dass es unerheblich ist, wo sich in Ihrem
+        Repository das Wurzelverzeichnis Ihres Projektes befindet.
+        Falls Sie nur ein Projekt pro Repository haben, ist der
+        logische Ort für das Wurzelverzeichnis des Projektes das
+        Wurzelverzeichnis des zum Projekt gehörenden Repositorys.
+        Falls Sie mehrere Projekte haben, möchten Sie diese vielleicht
+        innerhalb des Repositorys gruppieren, indem Sie Projekte mit
+        ähnlichen Zielen in demselben Unterverzeichnis unterbringen
+        oder sie vielleicht nur alphabetisch gruppieren. Eine solche
+        Anordnung könnte so aussehen:</para>
 
       <screen>
 /
@@ -468,19 +588,36 @@
       …
 </screen>
 
+<!--
       <para>Lay out your repository in whatever way you see fit.
         Subversion does not expect or enforce a particular layout—in
         its eyes, a directory is a directory is a directory.
         Ultimately, you should choose the repository arrangement that
         meets the needs of the people who work on the projects that
         live there.</para>
+-->
+      <para>Legen Sie Ihr Repository so an, wie es Ihnen passt.
+        Weder erwartet noch erzwingt Subversion eine bestimmte
+        Anordnung – für Subversion ist und bleibt ein
+        Verzeichnis ein Verzeichnis. Letztendlich sollten Sie für ein
+        Repository eine Struktur wählen, die den Bedürfnissen der
+        Leute gerecht wird, die an den Projekten arbeiten, die dort
+        untergebracht sind.</para>
 
+<!--
       <para>In the name of full disclosure, though, we'll mention
         another very common layout.  In this layout, the
         <filename>trunk</filename>, <filename>tags</filename>, and
         <filename>branches</filename> directories live in the root
         directory of your repository, and your projects are in
         subdirectories beneath those, like so:</para>
+-->
+      <para>Der Vollständigkeit halber erwähnen wir noch eine weitere,
+        verbreitete Anordnung. Bei dieser Anordnung befinden sich die
+        Verzeichnisse <filename>trunk</filename>,
+        <filename>tags</filename> und <filename>branches</filename> im
+        Wurzelverzeichnis des Repositorys und die Projekte in
+        Unterverzeichnissen davon:</para>
 
       <screen>
 /
@@ -501,6 +638,7 @@
       …
 </screen>
 
+<!--
       <para>There's nothing particularly incorrect about such a
         layout, but it may or may not seem as intuitive for your
         users.  Especially in large, multiproject situations with
@@ -515,6 +653,23 @@
         a single repository path that holds the entire
         history—past, present, tagged, and branched—for
         that project and that project alone.</para>
+-->
+      <para>An dieser Anordnung ist zwar nichts verkehrt, allerdings
+        könnte es für Ihre Benutzer mehr oder weniger intuitiv sein.
+        Besonders in Situationen mit vielen Projekten und entsprechend
+        vielen Benutzern, kann es vorkommen, dass die Benutzer
+        gewöhnlich nur mit einem oder zwei dieser Projekte vertraut
+        sind. Allerdings schwächt dieser
+        Projekt-als-Geschwister-Zweig-Ansatz die Betonung auf
+        Projekt-Individualität auf und betrachtet die Gesamtmenge der
+        Projekte als Ganzes. Das ist jedoch ein sozialer Aspekt. Wir
+        mögen unseren ursprünglich geäußerten Vorschlag aus rein
+        praktischen Erwägungen – es ist einfacher, in der
+        kompletten Historie eines einzelnen Projektes zu forschen
+        (oder sie zu verändern oder woandershin zu migrieren), wenn es
+        einen einzelnen Pfad im Repository gibt, der die gesamte
+        Historie für dieses eine Projekt, und nur dieses,  beinhaltet
+        – die Vergangenheit, Tags und Zweige.</para>
 
     </sect2>
 




More information about the svnbook-dev mailing list