Author: mbarkhau Date: Thu Aug 23 16:00:20 2007 New Revision: 1079 Log: Continued ch03
Modified: trunk/de/ch03.xml Modified: trunk/de/ch03.xml ============================================================================== --- trunk/de/ch03.xml (original) +++ trunk/de/ch03.xml Thu Aug 23 16:00:20 2007 @@ -37,12 +37,6 @@ Informationen verwaltet. Manche Anmerkungen werden "fürs Protokoll" gemacht, andere nicht. Das Protokoll selbst ist Gegenstand direkter Änderungen, und wird nicht als wörtliche Niederschrift der Ereignisse -verstanden, sondern als Niederschrift der Ereignisse auf die sich die -Gruppe <emphasis>einigen</emphasis> konnte. Das Protokoll ist nicht -monolitisch, sondern nimmt verschiedene Formen an, für verschieden -Zwecke. Es umfasst die Zeiten der einzelnen Sitzungen, die Zeiten aller -Sitzungen, Zusammenfassungen, Tagesordnungen und ihre Erläuterungen, -Gutachten von Ausschüssen und nicht anwesender Korrespondenten, auflistungen von Abläufen, usw.</para> <para>Da das Internet nicht wirklich ein Raum ist, müssen wir nicht die @@ -1175,183 +1169,177 @@ <varlistentry id="vc-vocabulary-checkout"> <term><firstterm>Checkout</firstterm></term> - <listitem><para>Der Vorgang, eine Kopie des Projekts vom Repository - zu beschaffen. Ein Checkout produziert für gewöhnlich eine - Verzeichnisstruktur welches als "working copy" (siehe unten) - bezeichnet wird, von dem aus Änderungen wieder zurück an die - Repository committed werden können. Bei manchen - dezentralisierten Versionsverwaltungssystemen ist jede Working - Copy selbst eine Repository, und Änderungen können an jede - Repository hoch-(oder herunter-) geladen werden, die bereit - ist sie anzunehmen.</para></listitem> + <listitem><para>Sich eine Kopie des Projekts aus der Repository zu + beschaffen. Ein Checkout produziert meistens eine + Verzeichnisstruktur welches als Arbeitsverzeichniss (siehe unten) + bezeichnet wird, von dem aus Änderungen wieder zurück in die + Repository übertragen werden können. Bei manchen dezentralisierten + Versionsverwaltungen ist jedes Arbeistverzeichniss selbst eine + Repository und Änderungen können an jede Repository hoch- oder + heruntergeladen werden die bereit ist sie + anzunehmen.</para></listitem> </varlistentry> <varlistentry id="vc-vocabulary-working-copy"> - <term><firstterm>working copy</firstterm></term> - <listitem><para>(de. Arbeitskopie) Der private Verzeichnisbaum eines - Entwicklers, welches die Source Code Dateien des Projekts und - möglicherweise seine Webseiten oder andere Dokumente beinhaltet. - Eine Arbeitskopie enthält auch ein wenig Metadaten, die von dem - Versionsverwaltungssystem benutzt werden, um zu Kennzeichen - woher von welchem Repository sie kommt, welche "revision" (siehe - Unten) der Dateien vorliegen, usw. Im allgemeinen hat jeder - Entwickler seine eigene Arbeitskopie, in welcher er seine - Änderungen macht und testet, und von dem aus er committed. - </para></listitem> - </varlistentry> + <term><firstterm>Arbeitsverzeichniss<footnote><para>engl. "working + copy"</para></footnote></firstterm></term> + <listitem><para>Der private Verzeichnisbaum eines Entwicklers, + mit dem Quellcode des Projekts und möglicherweise seine Webseite + oder andere Dokumente. Eine Arbeitskopie enthält auch ein paar + Metadaten, die von der Versionsverwaltung benutzt werden um zu + Kennzeichen von welcher Repository sie kommt, welche "Revision" + (siehe unten) der Dateien vorliegen, usw. Im allgemeinen hat jeder + Entwickler seine eigenes Arbeitsverzeichniss, indem er seine + Änderungen macht, prüft und seine Commits + macht.</para></listitem></varlistentry> <varlistentry id="vc-vocabulary-revision"> - <term><firstterm>revision</firstterm>, - <firstterm>change</firstterm>, - <firstterm>changeset</firstterm></term> - <listitem><para>Eine "revision" ist für gewöhnlich eine bestimmte - Version von einer Datei oder einem Verzeichnisses. Wenn das - Projekt zum Beispiel mit der revision 6 der Datei D anfängt, - und dann jemand eine Änderung an D committed, entsteht die - revision 7 von D. Manche Systeme benutzen "revision", "change" - (de. Änderung) oder "changeset" (de. Satz von Änderungen) auch - um einen ganzen Satz an Änderungen die zusammen committed - wurden als Einheit zu bezeichnen.</para> - - <para>Diese Begriffe haben ab und zu eine Bestimmte technische - Bedeutung bei verschiedenen Versionsverwaltungssystemen, im - allgemeinen ist die Idee immer die gleiche: Sie ermöglichen - es genau über bestimmte Zeitpunkte in der Geschichte der Datei - zu reden (wie, direkt vor und nachdem ein Bug behoben wurde). - Beispielsweise: "Ja, sie hat das in revision 10 behoben" oder - "Sie hat das in revision 10 von foo.c behoben."</para> - - <para>Wenn man von einer Datei oder einer Sammlung von Dateien - spricht ohne eine bestimmte revision anzugeben, wird im - Allgemeinen angenommen, dass man von der aktuellsten revision - spricht.</para></listitem> + <term><firstterm>Revision</firstterm><footnote><para> im engl. auch + <firstterm>change</firstterm> oder + <firstterm>changeset</firstterm> (de. Satz von + Änderungen)</para><footnote></term> + <listitem><para>Eine "Revision" ist für gewöhnlich eine bestimmte + Version einer Datei oder einem Verzeichniss. Wenn das Projekt z.B. + mit der revision 6 der Datei D anfängt und dann jemand eine Änderung + an D committed, entsteht die Revision 7 von D. Manche Systeme + benutzen "Revision" auch als Bezeichnung für einen ganzen Satz an + Änderungen die zusammen als Einheit committed wurden.</para> + + <para>Diese Begriffe haben ab und zu eine Bestimmte technische + Bedeutung abhänging von der Versionsverwaltung, im Allgemeinen ist + die Idee jedoch immer die gleiche: Sie ermöglichen es genau über + bestimmte Zeitpunkte in der Geschichte einer Datei zu reden (wie, + direkt vor und nachdem ein Fehler behoben wurde). Beispielsweise: + "Ja, sie hat das in Revision 10 behoben" oder "Sie hat das in + Revision 10 von foo.c behoben."</para> + + <para>Wenn man von einer Datei oder einer Sammlung von Dateien + spricht ohne eine bestimmte revision anzugeben, geht man im + Allgemeinen von der aktuellsten Revision aus.</para></listitem> </varlistentry> <sidebar id="version-vs-revision"> <title>"Version" kontra "Revision"</title> <para>Das Wort <firstterm>Version</firstterm> wird manchmal als - synonym für "revision" benutzt, ich werde es jedoch in diesem - Buch nicht auf diese Art verwenden, da es zu leicht zu - verwechseln ist mit "version" im sinne einer bestimmten - Version einer Software—also, mit einer Versionsnummer - wie "Version 1.0". Da jedoch, der Begriff Versionsverwaltung - bereits geläufig ist, werden ich es weiterhin benutzen.</para> + Synonym für "Revision" benutzt, ich werde es jedoch in diesem Buch + nicht auf diese Art verwenden da es zu leicht mit "Version" im + Sinne einer bestimmten Version einer Software—also eine + Veröffentlichung, mit einer Versionsnummer wie "Version 1.0", zu + verwechseln ist . Da der Begriff Versionsverwaltung bereits geläufig + ist, werden ich diesen trotzdem weiterhin verwenden.</para> </sidebar> <varlistentry id="vc-vocabulary-diff"> - <term><firstterm>diff</firstterm></term> - <listitem><para>(kurz für difference de. Unterschied) Eine textuelle - Representation einer Änderung. Ein diff zeigt welche Zeilen - geändert wurden und wie, sowie ein paar zusätzliche umgebende - Zeilen um einen Bezug zu haben. Ein Entwickler der bereits ein - wenig mit dem Code vertraut ist, kann für gewöhnlich ein diff - lesen und verstehen was die Änderung gemacht hat und sogar ein - Bugs bemerken.</para></listitem> + <term><firstterm>Diff<footnote><para>kurz für difference (de. + Unterschied)</para></footnote></firstterm></term> + Eine textuelle Representation einer Änderung. Ein Diff zeigt wie und + welche Zeilen geändert wurden, sowie ein paar zusätzliche Zeilen der + Umgebun für einen besseren Bezug. Ein Entwickler der bereits ein + wenig mit dem Code vertraut ist, kann für gewöhnlich ein Diff lesen + und verstehen was die Änderung gemacht hat und sogar Fehler + bemerken.</para></listitem> </varlistentry> <varlistentry id="vc-vocabulary-tag"> - <term><firstterm>tag</firstterm></term> - <listitem><para>(de. Etikett) Eine Kennzeichnung einer bestimmen - Sammlung von Dateien an bestimmten Revisionen. Tags werden - üblicherweise benutzt um interessante Revisionen des Projekts - zu erhalten. Für jede neue öffentliche Version wird zum Beispiel - ein neuer "Tag" gemacht, damit man sich genau den selben Satz - von Dateien/Revisionen aus dem Versionsverwaltungssystem - beschaffen kann. Häufige "Tag" Bezeichnungen sind sowas wie - <literal>Version_1_0</literal>, <literal>Auslieferung_00456 - </literal>, usw.</para></listitem> + <term><firstterm>Tag<footnote><para>de. + Etikett</para></footnote></firstterm></term> + <listitem><para>Eine Beschriftung einer bestimmen Menge an Dateien + ganz bestimmter Revisionen. Tags werden üblicherweise benutzt um + interessante Revisionen des Projekts zu bewahren. Für jede neue + veröffentlichte Version wird z.B. ein neuer "Tag" erstellt um später + genau dieselben Dateien/Revisionen aus der Versionsverwaltung + herunterladen zu können. Häufige "Tag" Bezeichnungen sind sachen wie + <literal>Version_1_0</literal>, + <literal>Auslieferung_00456</literal>, usw.</para></listitem> </varlistentry> <varlistentry id="vc-vocabulary-branch"> - <term><firstterm>branch</firstterm></term> - <listitem><para>(de. Ast) Eine Kopie des Projekts, welche zwar unter - Versionsverwaltung steht aber isoliert is, damit Änderungen - nicht das Übrige Projekt beeinflussen und umgekehrt, außer - wenn Änderungen absichtlich von einer Seite zur Anderen - "gemerged" werden (siehe unten). Ein Branch kann man auch als - Entwicklungszweig bezeichnen. Selbst wenn ein Projekt nicht - explizit irgend welche Branches hat, betrachtet man dennoch - den "main branch" auch "main line" oder "<firstterm>trunk - </firstterm>" als den Zweig auf dem die Entwicklung stattfindet. - </para> - - <para>Branches bieten eine Möglichkeit verschiedene Linien der - Entwicklung von einander zu trennen. Ein Branch kann zum - Beispiel für Experimentelle Entwicklung benutzt werden, die - für den Haupt Branch zu instabil wären. Oder umgekehrt kann - ein Branch als Ort benutzt werden um eine neue Version zu - stabilisieren. Während der Entwicklung, würde die reguläre - Entwicklung im Haupt Branch ohne Unterbrechung weitergehen - können; währenddessen werden auf dem Branch der neuen Version - keine Änderungen mehr zugelassen, außer sie werden von einem - Release Manager genehmigt. Auf diese Art, muss eine neue - Version nicht die laufende Entwicklungsarbeit stören. Siehe - <xref linkend="branches"/><phrase output="printed">später in - diesem Kapitel</phrase> für eine detailliertere Erörterung - von Branching.</para></listitem> + <term><firstterm>Zweig<footnote><para>engl. + branch</para></footnote></firstterm></term> + <listitem><para>Eine Kopie des Projekts in der Versionsverwaltung + die aber vom Hauptzweig isoliert ist, damit Änderungen nicht das + Übrige Projekt beeinflussen und umgekehrt, außer wenn Änderungen + absichtlich von einer Seite zur Anderen portiert werden (siehe + unten). Ein Branch kann man auch als Entwicklungszweig bezeichnen. + Selbst wenn ein Projekt nicht explizit irgendwelche Zweige hat, + gibt es dennoch einen sogenannten "Hauptzweig"<footnote><para>engl. + "main branch" auch "main line" oder + "<firstterm>trunk</firstterm>"</para></footnote>als den Zweig auf + dem die Entwicklung stattfindet.</para> + + <para>Zweige bieten die Möglichkeit verschiedene + Entwicklungsrichtungen von einander zu trennen. Ein Zweig kann z.B. + für Experimentelle Entwicklung benutzt werden, die für den + Hauptzweig nicht stabil genug wären. Umgekehrt kann ein Zweig auch + als Ort benutzt werden um eine neue Version zu stabil zu bekommen. + Während der Entwicklung kann die reguläre Entwicklung im Hauptzweig + ohne Unterbrechung weiterlaufen; währenddessen werden auf dem Zweig + der neuen Version keine Änderungen mehr zugelassen, außer sie werden + von einem Versionsverwalter genehmigt. Auf diese Art, muss eine neue + Version die laufende Entwicklung nicht stören. Siehe + <xref linkend="branches"/><phrase output="printed">später in diesem + Kapitel</phrase> für eine detailliertere Erörterung über + Zweige.</para></listitem> </varlistentry> <varlistentry id="vc-vocabulary-merge"> - <term><firstterm>merge (auch port)</firstterm></term> - <listitem><para>(de. Zusammenführung) Eine Änderung von einem Branch - in einen Anderen übernehmen. Was auch merging von dem trunk in - einen anderen Branch oder umgekehrt bedeuten kann. Tatsächlich - sind das sogar die häufigsten Merges; es ist selten eine - Änderung zwischen zwei Branches zu mergen, die nicht beide - Haupt-Zweige sind. Siehe <xref linkend="vc-singularity"/> - für mehr zu dieser Art von merging.</para> - - <para>"Merge" hat eine zweite, verwandte Bedeutung: Es ist das, - was das Versionsverwaltungssystem macht, wenn zwei Leute die - gleiche Datei bearbeitet haben, aber derart, dass sie sich nicht - überlappen. Da die Änderungen nicht mit einander kollidieren, - sobald einer der beiden seine Kopie der Datei aktualisiert - (welches bereits ihre eigenen Änderungen enthält), werden die - Änderungen der anderen Person gemerged. Das kommt sehr häufig - vor, besonders in Projekten, bei dem mehrere Entwickler am - gleichen Code hacken. Wenn zwei verschiedene Änderungen - <emphasis>doch</emphasis> überlappen, gibt es einen - "conflict"; siehe unten.</para> + <term><firstterm>Merge <footnote><para>im engl. auch "port" de. + Zusammenführung/Portierung</para></footnote></firstterm></term> + <listitem><para>Eine Änderung von einem Zweig in ein Anders + übernehmen. Was auch portieren von dem Hauptzweig in einem anderen + Zweig oder umgekehrt bedeuten kann. Tatsächlich sind das sogar die + häufigsten Merges; man portiert selten eine Änderung zwischen zwei + Zweige, die nicht beide Hauptzweige sind. Siehe + <xref linkend="vc-singularity"/> für mehr zu dieser Art zu + portieren.</para> + + <para>"Merge" hat eine zweite, verwandte Bedeutung: Die + Versionsverwaltung macht einen Merge, wenn zwei Leute die gleiche + Datei bearbeitet haben, sodass die Änderungen sich nicht überlappen. + Da die Änderungen nicht miteinander kollidieren, werden die + Änderungen in die eigenen Kopie (mit eigenen Änderungen) übertragen, + bzw. die Kopie wird aktualisiert. Das kommt sehr häufig vor, + besonders in Projekten bei dem mehrere Entwickler am gleichen Code + hacken. Wenn zwei verschiedene Änderungen <emphasis>doch</emphasis> + überlappen, gibt es einen "Konflikt"; siehe unten.</para> </listitem> </varlistentry> <varlistentry id="vc-vocabulary-conflict"> - <term><firstterm>conflict</firstterm></term> - <listitem><para>Was geschieht wenn zwei Personen gleichzeitig - unterschiedliche Änderungen an der gleichen Stelle im Code - vornehmen. Alle Versionsverwaltungssysteme erkennen Konflikte - automatisch, und benachrichtigen mindestens einer der - beteiligten Menschen, dass ihre Änderungen mit denen eines - Anderen Kollidieren. Es ist dann die Aufgabe des Menschen den - Konflikt zu beseitigen (en. resolve) und es an das - Versionsverwaltungssystem zu vermitteln.</para></listitem> + <term><firstterm>Konflikt</firstterm></term> + <listitem><para>Was geschieht wenn zwei Personen gleichzeitig + unterschiedliche Änderungen an der gleichen Stelle im Code vornehmen. + Jede Versionsverwaltung erkennt Konflikte automatisch, und + benachrichtigt mindestens einer der beteiligten Menschen, dass ihre + Änderungen mit denen einer Anderen Kollidieren. Der Konflikt muss + dann von einem Menschen gelöst (engl. <firstterm>resolve</firstterm>) + und an die Versionsverwaltung übermittelt werden.</para></listitem> </varlistentry> <varlistentry id="vc-vocabulary-lock"> - <term><firstterm>lock</firstterm></term> + <term><firstterm>Lock</firstterm></term> <listitem><para>(de. Schloss/Sperre) Eine Möglichkeit eine exklusive - Absicht auf eine Datei oder ein Verzeichnis zu erklären. Zum - Beispiel: "Ich kann gerade keine Änderungen an den Webseiten - committen. Es scheint das Alfred alle gesperrt hat (en. locked) - während er die Hintergrundbilder repariert". Nicht alle - Versionsverwaltungssysteme bieten überhaupt die Möglichkeit - zur Sperrung überhaupt an, und von denen die es tun, erfordern - nicht alle, dass sie auch benutzt wird. Das liegt daran, dass - parallele, gleichzeitige Entwicklung der Normalfall ist, und - Personen eine Datei für andere zu Sperren (gewöhnlicherweise) - diesem Ideal entgegensteht.</para> - - <para>Von Versionsverwaltungssystemen die einen lock erfordern um einen - commit zu machen, sagt man, dass sie das - <firstterm>lock-modify-unlock</firstterm> Modell benutzen. Solche - die es nicht erfordern nutzen das <firstterm>copy-modify-merge - </firstterm> Modell. Eine ausgezeichnete tiefgehende Erklärung - und Vergleich der beiden Modelle kann man bei <ulink - url="http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html"/> - finden. Im allgemeinen, ist die copy-modify-merge Methode besser - für die Open Source Entwicklung, und alle - Versionsverwaltungssysteme in diesem Buch unterstützen es.</para> - </listitem> + Absicht auf eine Datei oder ein Verzeichnis zu erklären. Z.B.: "Ich + kann gerade keine Änderungen an der Webseite machen. Es scheint das + Alfred alles gesperrt hat während er die Hintergrundbilder + korrigiert". Nicht jede Versionsverwaltung bieten überhaupt die + Möglichkeit Dateien zu sperren, und solche die es tun erfordern + nicht alle, dass sie auch benutzt wird. Das liegt daran, dass + parallele, gleichzeitige Entwicklung der Normalfall ist und Personen + eine Datei für andere zu sperren (üblichicherweise) diesem Ideal + widerspricht.</para> + + <para>Eine Versionsverwaltungs die einen Lock erfordern um ein + Commit zu machen, benutzt das sogenannte + <firstterm>lock-modify-unlock</firstterm> Verfahren. Solche die es + nicht erfordern nutzen das <firstterm>copy-modify-merge</firstterm> + Verfahren. Eine ausgezeichnete tiefgehende Erklärung und Vergleich + der beiden Methoden ist bei + <ulink url="http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html"/> + zu finden. Im allgemeinen ist die copy-modify-merge Methode besser + für die Open-Source Entwicklung und jede Versionsverwaltung in + diesem Buch unterstützen sie.</para> + </listitem> </varlistentry> </variablelist> @@ -1361,17 +1349,20 @@ <!-- ========================== subsection =========================== --> <sect2 id="vc-choosing"> -<title>Die Wahl eines Versionsverwaltungssystems</title> +<title>Wahl einer Versionsverwaltung</title> -<para>Bis dato, ist das Versionsverwaltungssystem der Wahl in der Welt -der freien Software das <firstterm>Concurrent Versions System -</firstterm> oder auch <firstterm>CVS</firstterm> (<ulink -url="http://www.cvshome.org/"/>). CVS gibt es schon seit langem. Die -meisten Erfahrenen Entwickler sind bereits damit vertraut, es erledigt -die Aufgabe mehr oder weniger gut und da es der Standard ist, werden -Sie keine langen Debatten darüber führen müssen ob es die richtige -Wahl war. CVS hat jedoch einige Nachteile. Es bietet keine einfache -Möglichkeit an sich auf Änderungen an mehreren Dateien gleichzeitig +<para>Zum Zeitpungkt dieses Schreibens sind die zwei verbreitetsten +Systeme für die Versionsverwaltung in der Welt der freien Software +das <firstterm>Concurrent Versions System</firstterm> oder auch +<firstterm>CVS</firstterm> (<ulink url="http://www.cvshome.org/"/>) +und <firstterm>Subversion</firstterm> (<firstterm>SVN</firstterm>, +<ulink url="http://subversion.tigris.org/"/>).</para> + +<para>CVS gibt es schon lange. Die meisten erfahrenen Entwickler sind +bereits damit vertraut, es erledigt die Aufgabe mehr oder weniger gut +und da es die Norm ist, werden Sie keine lange Debatten darüber führen +müssen ob es die richtige Wahl war. CVS hat jedoch einige Nachteile. +Es bietet keine einfache Möglichkeit an sich auf Änderungen an mehreren Dateien gleichzeitig zu beziehen; es erlaubt es nicht Dateien umzubenennen oder zu kopieren die unter Versionsverwaltung stehen (was besonders nervt, wenn Sie Ihr Code neu organisieren wollen, nachdem Sie das Projekt gestartet haben); _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
