root/traduc/branches/bv803/manuel/cvs.sgml

<!--
$Header: /var/lib/cvs/pgsql-fr/sgml/cvs.sgml,v 1.6 2005/03/25 21:49:17 guillaume Exp $
-->

<appendix id="cvs">
 <appendixinfo>
  <authorgroup>
   <author>
    <firstname>Marc</firstname>
    <surname>Fournier</surname>
   </author>
   <author>
    <firstname>Tom</firstname>
    <surname>Lane</surname>
   </author>
   <author>
    <firstname>Thomas</firstname>
    <surname>Lockhart</surname>
   </author>
  </authorgroup>
  <date>1999-05-20</date>
 </appendixinfo>

 <title>Dépôt <productname>CVS</productname></title>

 <para>
  Le code source de <productname>PostgreSQL</productname> est stocké et géré en
  utilisant le système de gestion de codes <productname>CVS</productname>.
 </para>

 <para>
  Au moins deux méthodes,
  CVS anonyme et <productname>CVSup</productname>,
  permettent d'extraire de <productname>CVS</productname> l'arborescence du
  code source du serveur <productname>PostgreSQL</productname> vers votre
  serveur local.
 </para>

 <sect1 id="anoncvs">
  <title>Obtenir les sources via <productname>CVS</productname> anonyme</title>

  <para>
    Si vous voulez mettre régulièrement à jour vos sources, vous pouvez les
    prendre de notre serveur <productname>CVS</productname>, puis utiliser
    <productname>CVS</productname> pour récupérer les mises à jour de temps
    en temps.
  </para>

  <procedure>
   <title>CVS anonyme</title>

   <step>
    <para>
     Vous aurez besoin d'une copie locale de <productname>CVS</productname>
     (Concurrent Version Control System), que vous pouvez obtenir depuis
     <ulink url="http://www.nongnu.org/cvs/">http://www.nongnu.org/cvs/</ulink>
     (le site officiel avec la dernière version) ou depuis n'importe quel site
     d'archive GNU (souvent peu à jour). Nous recommandons la version 1.10 ou
     la version la plus récente. Beaucoup de systèmes ont une version
     récente de <application>cvs</application> installé par défaut.
    </para>
   </step>

   <step>
    <para>
     Connectez-vous une première fois au serveur 
     <productname>CVS</productname>&nbsp;:

     <programlisting>
cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
     </programlisting>

     Un mot de passe vous est demandé. Vous pouvez entrer ce que vous voulez, 
     sauf une chaîne vide.
    </para>

    <para>
     Vous n'avez besoin de faire ceci qu'une seule fois car le mot de passe
     est sauvegardé dans le fichier <literal>.cvspass</literal> de votre répertoire
     personnel.
    </para>
   </step>

   <step>
    <para>
     Récupérez les sources de <productname>PostgreSQL</productname>&nbsp;:
     <programlisting>
cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
     </programlisting>

     Ceci installe les sources de <productname>PostgreSQL</productname> dans un 
     sous-répertoire <filename>pgsql</filename> de votre répertoire courant.

     <note>
      <para>
       Si vous avez une connexion rapide à Internet, vous n'avez peut-être pas
       besoin de l'option <option>-z3</option>, qui demande à 
       <productname>CVS</productname> de compresser les données à transférer avec gzip.
       À la vitesse d'un modem, cela permet un gain de temps substantiel.
      </para>
     </note>
    </para>

    <para>
     Cette extraction initiale est un peu plus lente que de simplement télécharger 
     un fichier <filename>tar.gz</filename>; attendez vous à ce qu'elle prenne
     40 minutes environ si vous avez un modem à 28,8&nbsp;Kbps. L'avantage de
     <productname>CVS</productname> n'apparaîtra que plus tard, lorsque vous voudrez
     mettre à jour les fichiers.
    </para>
   </step>

   <step>
    <para>
     Lorsque vous voulez mettre à jour vos sources <productname>CVS</productname>
     avec la dernière version, faites <command>cd</command> dans le sous-répertoire
    <filename>pgsql</filename> et lancez la commande
     <programlisting>
$ cvs -z3 update -d -P
     </programlisting>

     Ceci ne récupère que les modifications qui ont eu lieu depuis la dernière
     fois que vous avez fait une mise à jour. La mise à jour ne dure généralement
     que quelques minutes, même avec un simple modem.
    </para>
   </step>

   <step>
    <para>
     Vous pouvez économiser quelques saisies en vous faisant un fichier
     <filename>.cvsrc</filename> dans votre répertoire personnel ($HOME) en lui
     ajoutant&nbsp;:
     <programlisting>
cvs -z3
update -d -P
     </programlisting>

     Ceci ajoute l'option <option>-z3</option> à toutes les commandes cvs, et les options
     <option>-d</option> et <option>-P</option> aux mises à jour par cvs. Vous n'avez plus
     qu'à lancer
     <programlisting>
$ cvs update
     </programlisting>

     pour mettre à jour vos fichiers.
    </para>
   </step>
  </procedure>

  <caution>
   <para>
    Certaines versions anciennes de <productname>CVS</productname> ont un
    problème qui fait que tous les fichiers extraits ont des droits en
    écriture pour tout le monde. Si vous vous apercevez que cela vous
    arrive, vous pouvez faire quelque chose comme&nbsp;:
    <programlisting>
$ chmod -R go-w pgsql
    </programlisting>
    pour remettre les droits d'aplomb.
    Ce problème a été corrigé dans la version 1.9.28 de
    <productname>CVS</productname>.
   </para>
  </caution>

  <para>
   <productname>CVS</productname> peut faire de nombreuses autres
   choses, comme retrouver des versions antérieures des sources de
   <productname>PostgreSQL</productname> plutôt que les dernières
   versions de développement.
   Pour plus d'informations, consultez le manuel de
   <productname>CVS</productname> ou bien lisez la documentation en
   ligne à
   <ulink url="http://www.nongnu.org/cvs/">http://www.nongnu.org/cvs/</ulink>.
  </para>
 </sect1>

 <sect1 id="cvs-tree">
  <title>Organisation de l'arbre <productname>CVS</productname></title>

  <para>
   <note>
    <title>Auteur</title>
    <para>
     Écrit par Marc G. Fournier (<email>scrappy@hub.org</email>) 
     le 05/11/1998.
    </para>
   </note>
  </para>

  <para>
   La commande <command>cvs checkout</command> a un paramètre, <option>-r</option>,
   qui permet d'obtenir une révision particulière d'un module. Ce
   paramètre permet par exemple de retrouver les fichiers source de la
   version 6_4 du module 'tc' à tout moment dans le futur.

   <programlisting>
$ cvs checkout -r REL6_4 tc
   </programlisting>
   C'est en particulier utile si quelqu'un pense qu'il y a un problème
   dans cette version, mais que vous ne trouvez pas d'erreur dans
   la version courante.

   <tip>
    <para>
     Vous pouvez aussi extraire un module tel qu'il était à une date
     donnée en utilisant l'option <option>-D</option>.
    </para>
   </tip>
  </para>

  <para>
   Lorsque vous marquez plus d'un fichier avec une marque
   particulière, vous pouvez vous représenter la marque comme 
   <quote>une courbe tracée dans la matrice des noms de fichiers et
   des numéros de révision</quote>. Supposons que nous ayons 5 fichiers avec
   les révisions suivantes&nbsp;:

   <programlisting>
             fichier1 fichier2 fichier3 fichier4 fichier5

             1.1      1.1      1.1      1.1  /---1.1*    &lt;-*-  MARQUE
             1.2*-    1.2      1.2    --1.2*-
             1.3  \-- 1.3*-    1.3   /  1.3
             1.4           \   1.4  /   1.4
                            \--1.5*-    1.5
                               1.6
   </programlisting>

   alors la marque <literal>MARQUE</literal> référence
   fichier1-1.2, fichier2-1.3, etc.

   <note>
    <para>
     Pour créer une branche de version, à part l'option <literal>-b</literal>
     ajoutée sur la ligne de commande, c'est la même chose.</para>
    </note>
  </para>

  <para>
   Ainsi, pour créer la version 6.4, j'ai fait&nbsp;:

   <programlisting>
$ cd pgsql
$ cvs tag -b REL6_4
   </programlisting>
   ce qui créera la marque et la branche pour l'arbre de la version.
  </para>

  <para>
   Pour ceux qui ont un accès <productname>CVS</productname>, il est
   simple de créer des répertoires séparés pour chaque version.
   D'abord, créez deux répertoires, VERSION et COURANT, afin de ne
   pas les mélanger. Puis&nbsp;:

   <programlisting>
cd RELEASE
cvs checkout -P -r REL6_4 pgsql
cd ../CURRENT
cvs checkout -P pgsql
   </programlisting>

   Cela crée deux arbres de répertoires, <filename>VERSION/pgsql</filename> et
   <filename>COURANT/pgsql</filename>. À partir de ce moment,
   <productname>CVS</productname> gardera trace de quel arbre de
   référence est dans quel répertoire, et permettra des mises à jour
   indépendantes de chaque arbre.
  </para>

  <para>
   Si vous ne travaillez <emphasis>que</emphasis> sur l'arbre
   <literal>CURRENT</literal>, faites tout ce qui est indiqué jusqu'à
   ce que nous ayons commencé à marquer les branches de versions.
  </para>

  <para>
   Après avoir fait l'extraction initiale d'une branche

   <programlisting>
$ cvs checkout -r REL6_4
   </programlisting>

   tout ce que vous faites dans ce répertoire est limité à cette branche.
   Si vous appliquez une correction à cette structure de répertoires
   et faites un

   <programlisting>
cvs commit
   </programlisting>

   dans ce répertoire, la correction est appliquée à cette branche et
   <emphasis>seulement</emphasis> à cette branche.
  </para>
 </sect1>

 <sect1 id="cvsup">
  <title>Obtenir les sources via <productname>CVSup</productname></title>

  <para>
   Une alternative au CVS anonyme pour obtenir l'arbre source de 
   <productname>PostgreSQL</productname> est
   <productname>CVSup</productname>.
   <productname>CVSup</productname> a été développé par John Polstra
   (<email>jdp@polstra.com</email>) pour distribuer des arbres de
   référence CVS et d'autres arborescences de fichiers pour le
   <ulink url="http://www.freebsd.org">projet FreeBSD</ulink>.
  </para>

  <para>
   Un des avantages majeurs de <productname>CVSup</productname> est
   qu'il peut répliquer fiablement la <emphasis>totalité</emphasis>
   du référentiel CVS sur votre système local, ce qui permet un accès
   rapide aux opérations CVS comme <option>log</option> ou
   <option>diff</option>.
   Autre avantage, la synchronisation efficace avec le serveur
   <productname>PostgreSQL</productname> grâce à un protocole de flux
   de transfert qui ne transmet que les différences depuis la
   dernière mise à jour.
  </para>

  <sect2>
   <title>Préparer un système client <productname>CVSup</productname></title>

   <para>
    Deux groupes de répertoires sont nécessaires à
    <productname>CVSup</productname>&nbsp;: un répertoire contenant le
    référentiel <productname>CVS</productname> local (ou simplement
    un groupe de répertoires si vous ne récupérez qu'un extrait plutôt
    que le référentiel complet&nbsp;; voir plus loin) et une zone dans
    laquelle <productname>CVSup</productname> enregistre ses propres
    données. Ces deux groupes de répertoires peuvent coexister dans la
    même arborescence.
   </para>

   <para>
    Décidez où vous souhaitez garder votre copie locale du référentiel
    <productname>CVS</productname>. Sur un de nos systèmes, nous
    avons récemment créé un référentiel dans
    <filename>/home/cvs/</filename>, mais nous avions jusque là utilisé
    <filename>/opt/postgres/cvs/</filename> comme arbre de développement
    pour <productname>PostgreSQL</productname>. Si vous souhaitez
    placer votre référentiel dans <filename>/home/cvs/</filename>,
    alors ajoutez

    <programlisting>
setenv CVSROOT /home/cvs
    </programlisting>

    dans votre fichier <filename>.cshrc</filename>, ou une ligne
    similaire dans votre <filename>.bashrc</filename> ou dans votre
    <filename>.profile</filename>, en fonction de votre interpréteur
    de commandes (shell).
   </para>

   <para>
    La zone de référentiel de <application>cvs</application> doit
    être initialisée. Une fois que <envar>CVSROOT</envar> est
    initialisée, il suffit de faire&nbsp;:

    <programlisting>
$ cvs init
    </programlisting>

    après quoi vous devriez au moins voir un répertoire
    <filename>CVSROOT</filename> en listant le répertoire
    <envar>CVSROOT</envar>&nbsp;:

    <programlisting>
$ ls $CVSROOT
CVSROOT/
    </programlisting>
   </para>
  </sect2>

  <sect2>
   <title>Utiliser un client <productname>CVSup</productname></title>

   <para>
    Vérifiez que <application>cvsup</application> est dans votre
    chemin. Sur la plupart des systèmes, cela se fait en tapant

    <programlisting>
which cvsup
    </programlisting>

    Puis, lancez simplement
    <application>cvsup</application> en faisant&nbsp;:

    <programlisting>
$ cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
    </programlisting>

    où <option>-L 2</option> active certains messages de statut pour
    vous permettre de suivre le progrès pour la mise à jour et
    <replaceable class="parameter">postgres.cvsup</replaceable> est
    la chemin et le nom que vous avez donné à votre fichier de
    configuration <productname>CVSup</productname>.
   </para>

   <para>
    Voici un fichier de configuration <productname>CVSup</productname>
    modifié pour une installation spécifique, et maintient un
    référentiel <productname>CVS</productname> local complet.

    <programlisting>
# Ce fichier représente le fichier de distribution CVSup standard
# pour le projet de SGBDRO <productname>PostgreSQL</>
# Modifié par lockart@fourpalms.org 1997-08-28
# - Pointe vers mon arborescence de référence locale
# - Extrait le référentiel CVS complet, pas seulement la
#   dernière version
#
#Valeurs par défaut qui s'appliquent à toutes les collections
*default host=cvsup.postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
# Activez la ligne suivante pour récupérer la dernière version
#*default tag=.
# Activez la ligne suivante récupérer ce qui est précisé en dessus ou 
# par défaut à la date précisée en dessous
#*default date=97.08.29.00.00.00

# répertoire de base où CVSup stocke ses fichiers 'marque page'
# créera un sous répertoire sup/
#*default base=/opt/postgres # /usr/local/pgsql
*default base=/home/cvs

# répertoire préfixe où CVSup stocke les distributions.
*default prefix=/home/cvs

# Distribution complète, avec tout ce qui est en dessous
pgsql

# distributions partielles
# pgsql-doc
# pgsql-perl5
# pgsql-src

   </programlisting>
   </para>

   <para>
    Si vous indiquez <option>repository</> au lieu de <option>pgsql</> dans la
    configuration précédente, vous obtiendrez une copie complète du dépôt sur
    cvsup.postgresql.org, incluant son répertoire <filename>CVSROOT</filename>.
    Si vous faites cela, vous voudrez probablement exclure ces fichiers du
    répertoire que vous voulez modifier localement, en utilisant un fichier
    nommé refuse. Par exemple, pour la configuration précédente, vous auriez
    pu placer ceci dans <filename>/home/cvs/sup/repository/refuse</>&nbsp;:
<programlisting>
CVSROOT/config*
CVSROOT/commitinfo*
CVSROOT/loginfo*
</programlisting>
    Voir les pages man de <productname>CVSup</> pour savoir comment utiliser
    les fichiers refuse.
</para>

   <para>
    Ce qui suit est une suggestion de fichier de configuration 
    <productname>CVSup</productname> issu du
    <ulink url="ftp://ftp.postgresql.org/pub/CVSup/README.cvsup">
    site ftp de <productname>PostgreSQL</></ulink>, qui
    ne récupère que la version courante&nbsp;:

    <programlisting>
# Ce fichier représente la distribution CVSup standard pour le
# projet de SGBDRO <productname>PostgreSQL</>.
#
# Valeurs par défaut qui d'appliquent à toutes les collections.
*default host=cvsup.postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.

# répertoire de base où CVSup stocke ses fichiers 'marque page'
*default base=<replaceable class="parameter">/usr/local/pgsql</replaceable>

# répertoire préfixe où CVSup stocke les distributions.
*default prefix=<replaceable class="parameter">/usr/local/pgsql</replaceable>

# Distribution complète, avec tout ce qui est en dessous
pgsql

# distributions partielles
# pgsql-doc
# pgsql-perl5
# pgsql-src

    </programlisting>
   </para>
  </sect2>

  <sect2>
   <title>Installer <productname>CVSup</productname></title>

   <para>
    <productname>CVSup</productname> est disponible sous forme de 
    fichiers source, de binaires pré-compilés ou de RPM Linux.
    Il est beaucoup plus simple d'utiliser les binaires plutôt que de
    compiler les sources, principalement parce que cela nécessite
    le compilateur Modula-3, qui est très puissant mais volumineux.
   </para>

   <procedure>
    <title>Installation de <productname>CVSup</productname> à partir des fichier binaires</title>

    <para>
     Vous pouvez utiliser les binaires pré-compilés si vous avez une
     plate-forme pour laquelle les binaires sont postés sur le
     <ulink url="ftp://ftp.postgresql.org/pub">site ftp de <productname>PostgreSQL</productname></ulink>,
     vous pouvez ou si avez FreeBSD, pour lequel 
     <productname>CVSup</productname> est disponible comme
     <quote>portage</quote>.

     <note>
      <para>
       <productname>CVSup</productname> a été initialement développé
       pour distribuer l'arbre des sources de
       <productname>FreeBSD</productname>. Il est disponible comme
       <quote>portage</quote>, et pour ceux qui ont FreeBSD, si cela 
       n'explique pas suffisamment comment obtenir et installer CVSup,
       merci d'ajouter une procédure ici.
       </para>
     </note>
    </para>

    <para>
     Au moment de l'écriture de ce chapitre, des binaires sont
     disponibles pour&nbsp;: 
     Alpha/Tru64, ix86/xBSD,
     HPPA/HP-UX 10.20, MIPS/IRIX,
     ix86/linux-libc5, ix86/linux-glibc,
     Sparc/Solaris et Sparc/SunOS.
    </para>

    <step>
     <para>
      Récupérez l'archive tar des binaires
      <application>cvsup</application>
      (<application>cvsupd</application> n'est pas nécessaire pour
       être un client) approprié pour votre plate-forme.
     </para>

     <substeps>
      <step performance="optional">
       <para>
        Si vous avez FreeBSD, installez le portage 
        <productname>CVSup</productname>.
       </para>
      </step>

      <step performance="optional">
       <para>
        Si vous avez une autre plate-forme, vérifiez et télécharger le 
        binaire approprié
        <ulink url="ftp://ftp.postgresql.org/pub">du site ftp <productname>PostgreSQL</productname></ulink>.
       </para>
      </step>
     </substeps>
    </step>

    <step>
     <para>
      Vérifiez dans l'archive tar les contenus et la structure
      de répertoires. Pour le tar Linux au moins, le binaire statique
      et la page de manuel sont inclues sans répertoires.
    </para>

     <substeps>
      <step>
       <para>
        Si le binaire est au plus haut niveau du fichier tar, alors
        il suffit d'extraire le fichier tar dans le répertoire cible&nbsp;:

        <programlisting>
$ cd /usr/local/bin
$ tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz
$ mv cvsup.1 ../doc/man/man1/
        </programlisting>
       </para>
      </step>

      <step>
       <para>
        S'il y a une structure de répertoires dans le fichier tar,
        alors extrayez le dans /usr/local/src et déplacez les binaires
        dans le répertoire approprié, comme indiqué ci-dessus.
      </para>
      </step>
     </substeps>
    </step>

    <step>
     <para>
      Assurez-vous que les nouveaux binaires sont dans votre chemin.

      <programlisting>
$ rehash
$ which cvsup
$ set path=(<replaceable>chemin de cvsup</replaceable> $path)
$ which cvsup
/usr/local/bin/cvsup
      </programlisting>
     </para>
    </step>
   </procedure>
  </sect2>

  <sect2>
   <title>Installation à partir des sources</title>

   <para>
    Installer <productname>CVSup</productname> n'est pas entièrement
    trivial, principalement parce que la plupart des systèmes auront
    besoin du compilateur Modula-3.

    Ce compilateur est disponible sous forme de 
    <productname>RPM</productname> Linux, de paquetage FreeBSD ou de
    code source.

    <note>
     <para>
      Une installation de Modula-3 avec les sources prend environ
      200&nbsp;Mo d'espace disque, qui redescendent ensuite à environ 50&nbsp;Mo
      lorsque les sources sont supprimées.</para>
    </note>
   </para>

   <procedure>
    <title>Installation sur Linux</title>

    <step>
     <para>
      Installer Modula-3.
     </para>

     <substeps>
      <step>
       <para>
        Récupérer la distribution de <productname>Modula-3</productname>
        à <ulink url="http://m3.polymtl.ca/m3">Polytechnique Montréal</ulink>,
        qui maintient activement le code initialement développé par le
        <ulink
            url="http://www.research.digital.com/SRC/modula-3/html/home.html">centre
            de recherches système de DEC</ulink>.
            La distribution <productname>PM3</productname> sous forme de 
            <productname>RPM</productname> fait environ 30&nbsp;Mo compressée.
            Au moment de l'écriture de ce document, la version 1.1.10-1
            s'installe sans problème sur RH-5.2, alors que la version
            1.1.11-1 est apparemment prévue pour une autre version 
            (RH-6.0?) et ne fonctionne pas sous RH-5.2.

        <tip>
         <para>
          Cette distribution rpm spécifique a de <emphasis>nombreux</emphasis>
          fichiers <productname>RPM</productname>, si bien que vous 
          voudrez sans doute les mettre dans un répertoire séparé.
         </para>
        </tip>
       </para>
      </step>

      <step>
       <para>
        Installer les rpms Modula-3&nbsp;:

        <programlisting>
# rpm -Uvh pm3*.rpm
        </programlisting>
       </para>
      </step>
     </substeps>
    </step>

    <step>
     <para>
     Décompresser la distribution CVSup&nbsp;:

      <programlisting>
# cd /usr/local/src
# tar zxf cvsup-16.0.tar.gz
      </programlisting>
     </para>
    </step>

    <step>
     <para>
      Compiler la distribution cvsup, en supprimant l'interface 
      graphique pour éviter d'utiliser les bibliothèques X11.
 
      <programlisting>
# make M3FLAGS="-DNOGUI"
      </programlisting>

      et si vous voulez construire un binaire statique pour l'utiliser
      sur des systèmes qui n'ont pas Modula-3 installé, essayez&nbsp;:

      <programlisting>
# make M3FLAGS="-DNOGUI -DSTATIC"
      </programlisting>
     </para>
    </step>

    <step>
     <para>
      Installer la librairie construite précédemment&nbsp;:

      <programlisting>
# make M3FLAGS="-DNOGUI -DSTATIC" install
      </programlisting>
     </para>
    </step>
   </procedure>
  </sect2>
 </sect1>
</appendix>

<!--
> It became clear that I had a problem with my m3 installation; some
> X11 libraries were not being found correctly.

By the way, you can build the client without the GUI by doing this
in the "client" subdirectory:

    m3build -DNOGUI

If you build it that way, then it doesn't need the X11 libraries and
it's quite a bit smaller.  The GUI is fun to watch, but it's not
very useful.  I originally implemented it because it made debogueging
the multi-threaded client program much easier.

To build a statically-linked client, edit <filename>client/src/m3makefile</filename>
to add <literal>build_standalone()</literal>
 just before the <literal>program()</literal> entry near
the end of the file:

<programlisting>
build_standalone()
program(cvsup)
</programlisting>

Then, if cvsup has already been built, remove the machine-specific build directory
(e.g. <filename>LINUXELF/</filename>) and rebuild:

<programlisting>
rm -rf LINUXELF
m3build -DNOGUI -v
cp -p LINUXELF/cvsup /usr/local/bin
</programlisting>

> Anyway, with the reinstall and the two-line patch above (and that
> one include-file _POSIX_SOURCE workaround from the previous try),
> things built cleanly.

Good!

> Now I just need a server somewhere to test.

If you want to try it out, there are public servers for the FreeBSD
source repository at cvsup.freebsd.org and cvsup2.freebsd.org.
Here's a suggested supfile:

*default host=cvsup.freebsd.org compress
*default release=cvs
*default base=/home/jdp/cvsup-test      # FIX THIS
*default delete use-rel-suffix
# *default tag=.
src-bin

This will fetch you the source repository for the programs that get
installed into "/bin".  I chose it because it's one of the smaller
pieces of the system.  Make an empty directory someplace for
testing, and change the "FIX THIS" line to specify that directory
after the "base=".

If you are on a T1 or better, you should probably delete the
"compress" keyword in the first line.

As shown, it will get the repository (RCS) files.  If you uncomment
the line containing "tag=." then it will instead check out the
latest version of each file.  There's a bunch more information about
what you can do in
<ulink url="http://www.freebsd.org/handbook/cvsup.html">the CVSup Handbook</ulink>.

There is one other thing I want to send you, but not tonight.  I
discovered the hard way that you need a malloc package that is
thread-safe with respect to the Modula-3 threads package.  The
Modula-3 runtime takes care to do the proper mutual exclusion around
all calls it makes to malloc.  But if you call certain functions in
the native C library which in turn call malloc, then the mutual
exclusion gets bypassed.  This can lead to rare but baffling core
dumps.

For FreeBSD, I solved this by adding a thread-safe malloc package
into the Modula-3 runtime.  The package is quite portable, and I'm
sure it will work well for Linux with very few changes (probably
none at all).  I want to send it to you along with instructions
for making it a part of the "libm3core" library.  It's very simple,
but I've run out of steam for tonight. :-)  Once you have this
malloc in place, the CVSup system should be rock solid.  We have
servers that have been up for weeks and have served many thousands
of clients without any observed problems.

> We hope to have the PostgreSQL tree using CVSup within a month or
> so, and hope to retire sup in September...

Great!  I'll do my best to help make sure you don't regret it.

John

Tom,

I'm appending the sources for the thread safe version of malloc that
I told you about.  I believe that it will simply compile and work
under Linux, but I've never had an opportunity to test it there.
I urge you to put it into your Modula-3 system; otherwise, you
are guaranteed to get occasional mysterious core dumps from cvsupd.

As a first step, I'd suggest simply trying to compile it under
Linux, like this:

    cc -O -c malloc.c

You shouldn't get any errors or warnings.  If you do, contact me
before you waste any more time on it.

Assuming it compiles OK, copy malloc.c into this directory of your
Modula-3 source tree:

    m3/m3core/src/runtime/LINUXELF

In that same directory, edit "m3makefile" and add this line to the
end of the file:

    c_source       ("malloc")

Then chdir up into "m3/m3core" of the Modula-3 tree and type
"m3build".  (I'm assuming you already have a working Modula-3
installation.)  After that finishes, become root and type "m3ship"
to install it.

That's all there is to it.  If you built cvsup and cvsupd to use
shared libraries, you don't even need to re-link them.  They'll pick
up the change automatically from the updated shared library.

Let me know if you run into any problems with it.

By the way, this is a very good malloc in its own right.  It's worth
using even aside from the thread safety of it.

Regards,
John

I've deposited a statically built cvsup client executable (and man pages
and test configuration) in

  /pub/incoming/cvsup-15.1-client-linux.tar.gz

This was built and linked on Linux/v2.0.30, RH/v4.2, gnulib/v5.3.12 and
includes the thread-safe malloc provided by John Polstra. I'll forward
to you the malloc code and an additional installation e-mail from John.

The Modula-3 installation takes a good bit of room (~50MB?) and the
build environment is unique to Modula-3, but suprisingly enough it
pretty much works.

The cvsup Makefiles do not work on my machine (they are not portable
yet) but each major package (there are 4) can be built without needing
the makefiles with two commands each. Not difficult at all. John gives
some hints in his e-mail on how to build a static executable, and on how
to shrink the size of the executable by leaving out the GUI support.
Again, easy to do.

My client test case, picking up a sub-tree of the FreeBSD distribution,
worked flawlessly. I haven't tried running a server.

Thanks to John for getting me going.

                        - Tom


For the thread-safe malloc, do the following:
1) install Modula-3
2) add the enclosed file "malloc.c" to m3/m3core/src/runtime/LINUXELF
3) edit the last line of m3makefile in the same directory to add
     c_source       ("malloc")
4) do an "m3build" and an m3ship from the appropriate directory.

>From what John said, the malloc problem can be noticable for the
server-side running cvsupd. Clients may not need it.

Unfortunately I seem to have lost John's original good instructions for
this, so am doing this from memory. May need to ask John to give
instructions again...

                        - Tom

-->


<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->