X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fdokumentation.xml;h=0a61691068478450318eafb26cd0455da19231ae;hb=8bde65163db8c36ffa5e83bed7ee68ab859c106d;hp=3635f6228746fe6c888efffa6069e7ff9c34be19;hpb=dbda14c263efd93aca3b7114015a47d86b8581e3;p=kivitendo-erp.git

diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml
index 3635f6228..0a6169106 100644
--- a/doc/dokumentation.xml
+++ b/doc/dokumentation.xml
@@ -80,7 +80,7 @@
             <para>Debian</para>
             <itemizedlist>
                <listitem>
-                 <para>6.0 "Squeeze" (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden)</para>
+                 <para>6.0 "Squeeze" (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden, und <literal>Rose::DB::Object</literal> ist zu alt)</para>
                </listitem>
                <listitem>
                  <para>7.0 "Wheezy"</para>
@@ -93,7 +93,7 @@
           </listitem>
 
           <listitem>
-            <para>openSUSE 12.1 und 12.2</para>
+            <para>openSUSE 12.2 und 12.3</para>
           </listitem>
 
           <listitem>
@@ -160,7 +160,7 @@
 
           <listitem><para><literal>Rose::DB</literal></para></listitem>
 
-          <listitem><para><literal>Rose::DB::Object</literal></para></listitem>
+          <listitem><para><literal>Rose::DB::Object</literal> Version 0.788 oder neuer</para></listitem>
 
           <listitem><para><literal>Template</literal></para></listitem>
 
@@ -175,6 +175,8 @@
           <listitem><para><literal>YAML</literal></para></listitem>
         </itemizedlist>
 
+        <para>Seit v3.0.0 sind die folgenden Pakete hinzugekommen: <literal>File::Copy::Recursive</literal>.</para>
+
         <para>Seit v2.7.0 sind die folgenden Pakete hinzugekommen: <literal>Email::MIME</literal>, <literal>Net::SMTP::SSL</literal>,
         <literal>Net::SSLGlue</literal>.</para>
 
@@ -5458,29 +5460,17 @@ file = /tmp/kivitendo-debug.log</programlisting>
              xreflabel="Einführung in die Datenbank-Upgradedateien">
         <title>Einführung</title>
 
-        <para>Der alte Mechanismus für SQL-Upgradescripte, der auf einer
-        Versionsnummer beruht und dann in sql/Pg-upgrade nach einem Script für
-        diese Versionsnummer sucht, schränkt sehr ein, z.B. was die parallele
-        Entwicklung im stable- und unstable-Baum betrifft.</para>
-
-        <para>Dieser Mechanismus wurde für kivitendo 2.4.1 deutlich erweitert.
-        Es werden weiterhin alle Scripte aus sql/Pg-upgrade ausgeführt.
-        Zusätzlich gibt es aber ein zweites Verzeichnis, sql/Pg-upgrade2. In
-        diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren,
-        die neben den eigentlich auszuführenden SQL- oder Perl-Befehlen einige
-        Kontrollinformationen enthält.</para>
-
-        <para>Neu sind die Kontrollinformationen, die Abhängigkeiten und
-        Prioritäten definieren können werden, sodass Datenbankscripte zwar in
-        einer sicheren Reihenfolge ausgeführt werden (z.B. darf ein "ALTER
-        TABLE" erst ausgeführt werden, wenn die Tabelle mit "CREATE TABLE"
-        angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man
-        keine Versionsnummern mehr braucht.</para>
-
-        <para>kivitendo merkt sich dabei, welches der Upgradescripte in
-        sql/Pg-upgrade2 bereits durchgeführt wurde und führt diese nicht
-        erneut aus. Dazu dient die Tabelle "schema_info", die bei der
-        Anmeldung automatisch angelegt wird.</para>
+        <para>Datenbankupgrades werden über einzelne Upgrade-Scripte gesteuert, die sich im Verzeichnis <filename>sql/Pg-upgrade2</filename>
+        befinden. In diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren, die neben den eigentlich auszuführenden SQL- oder
+        Perl-Befehlen einige Kontrollinformationen enthält.</para>
+
+        <para>Kontrollinformationen definieren Abhängigkeiten und Prioritäten, sodass Datenbankscripte zwar in einer sicheren Reihenfolge
+        ausgeführt werden (z.B. darf ein <literal>ALTER TABLE</literal> erst ausgeführt werden, wenn die Tabelle mit <literal>CREATE
+        TABLE</literal> angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man keine Versionsnummern braucht.</para>
+
+        <para>kivitendo merkt sich dabei, welches der Upgradescripte in <filename>sql/Pg-upgrade2</filename> bereits durchgeführt wurde und
+        führt diese nicht erneut aus. Dazu dient die Tabelle "<literal>schema_info</literal>", die bei der Anmeldung automatisch angelegt
+        wird.</para>
       </sect2>
 
       <sect2 id="db-upgrade-files.format"
@@ -5954,6 +5944,10 @@ filenames</programlisting>
           Perl-Distribution und kann für frühere Versionen aus dem <ulink url="http://www.cpan.org">CPAN</ulink> bezogen
           werden.</para></listitem>
         </itemizedlist>
+
+        <para>Weitere Voraussetzung ist, dass die Testsuite ihre eigene Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
+        müssen in der Konfigurationsdatei im Abschnit <literal>testing/database</literal> Datenbankverbindungsparameter angegeben
+        werden. Der hier angegebene Benutzer muss weiterhin das Recht haben, Datenbanken anzulegen und zu löschen.</para>
       </sect2>
 
       <sect2 id="devel.testsuite.execution">
@@ -5962,14 +5956,14 @@ filenames</programlisting>
         </title>
 
         <para>Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder, man lässt alle Tests auf einmal ausführen, oder man führt
-        gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript <filename>t/test.sh</filename>.</para>
+        gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript <filename>t/test.pl</filename>.</para>
 
-        <para>Will man die komplette Test-Suite ausführen, so muss man einfach nur <filename>t/test.sh</filename> ohne weitere Parameter aus
+        <para>Will man die komplette Test-Suite ausführen, so muss man einfach nur <filename>t/test.pl</filename> ohne weitere Parameter aus
         dem kivitendo-Basisverzeichnis heraus ausführen.</para>
 
-        <para>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <filename>t/test.sh</filename>. Beispielsweise:</para>
+        <para>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <filename>t/test.pl</filename>. Beispielsweise:</para>
 
-        <programlisting>t/test.sh t/form/format_amount.t t/background_job/known_jobs.t</programlisting>
+        <programlisting>t/test.pl t/form/format_amount.t t/background_job/known_jobs.t</programlisting>
       </sect2>