\documentclass[pdf,colorBG,slideColor,azure]{prosper}

\usepackage{epsfig}

\title{CVS - the Concurrent Versioning System}
\subtitle{Un introduction au contr\^ole des sources}
\author{Dave Neary}

\begin{document}

\maketitle

\begin{slide}{Plan d'atelier}
\begin{itemize}
  \item[Partie 1] Qu'est-ce qu'est CVS? Un introduction au 
  travail collaboratif
  \item[Partie 2] CVS en pratique - les commandes les plus
  courantes
  \item[Partie 3] Travailler avec des branches
  \item[Partie 4] Survol de l'administration de CVS
\end{itemize}
\end{slide}

\overlays{4}{%
\begin{slide}{Introduction}
  Qu'est-ce que c'est, CVS?

  \begin{itemstep}
    \item CVS est un application qui permet le suivi des fichiers
    dans le temps.
    \item Il est un serveur centrale pour le stockage des
    fichiers
    \item Quand des gens avec des copies font des changements,
    ces changements sont envoy\'e au serveur pour \^etre
    int\'egr\'e dans la copie sur le serveur.
    \item De temps en temps, tout les gens qui ont un copie des
    documents peuvent se mettre \`a jour avec tout les
    changements que d'autres gens ont fait.
  \end{itemstep}
\end{slide}
}

\overlays{4}{%
\begin{slide}{Aux quels probl\`emes addresse-t-il?}

CVS est concu pour aider avec certains probl\`emes du travail
commaboratif.

  \begin{itemstep}
    \item Renversement des erreurs
    \item Recreation d'anciens versions
    \item Developpement concurrent
    \item Cooperation entre plusieurs d\'eveloppeurs
  \end{itemstep}
\end{slide}
}


\begin{slide}{Renversement des erreurs}

    Si on ne garde pas un copie des anciens sources, on est
    vraiement dans la merde si on fait une erreur qu'on ne peut
    pas enlever apr\`es.

\end{slide}

\begin{slide}{Recreation d'anciens versions}

    Notre client principale dis qu'il a trouv\'e une bogue. Dans
    notre version, on ne le voit pas. Peut \^etre on l'a 
    r\'epar\'e, peut \^etre il n'y a pas vraiement de bogue. 
    Sans pouvoir revenir au version exacte qu'il a, on est dans 
    la merde.

\end{slide}

\begin{slide}{Developpement concurrent}

\begin{itemize}
    \item On fait du d\'eveloppement d'une version stable et une 
    version d\'eveloppement de notre produit au m\^eme temps. 
    
    \item Mais quand on corrige une bogue dans notre version stable, 
    comment l'int\'egrer dans notre version d\'eveloppement? Et 
    \'egalement dans l'autre sense?

    \item De plus, comment savoir ce qui a chang\'e depuis qu'on a
    commenc\'e la s\'eparation? Comment r\'epr\'esenter ce racine
    commun?
\end{itemize}
\end{slide}

\begin{slide}{Coop\'eration entre plusieurs d\'eveloppeurs}

\begin{itemize}
    \item Jacques a fait un super boulot. Il a mis au point le 
    produit, et on deviendra le Market Leader.

    \item Malheureusement, un peu plus tard, Phillippe d\'econne en
    \'ecrasant le travail de Jacque avec son super patch qui
    enl\`eve toutes espaces blanches non-requises dans les codes
    sources. 
    
    \item Tant pis, et on est dans la merde encore. Comment
    r\'ecup\'erer le travail de Jacques?
\end{itemize}

\end{slide}

\overlays{3}{
\begin{slide}{Probl\`emes pas address\'e par CVS}
    
    \begin{itemstep}
      \item Communication
      \item Gestion
      \item Build
    \end{itemstep}

\end{slide}
}

\begin{slide}{Communication}
  \begin{itemize}
    \item CVS n'a aucun connaissance de C, ou Java, ou HTML. Si
    il y a une conflit entre le travail de deux personnes, il
    faut communiquer.
    \item Si un changement qu'on fait dans un fichier casse
    d'autres fichiers, CVS ne sais rien.
    \item Si Harry attend que le fonction ``getSaltyRasher''
    retourne un ``SaltyRasher *'', mais Cathy d\'ecide qu'il faut
    mieux retourner un ``int'', tant pis pour Harry.
  \end{itemize}
\end{slide}

\begin{slide}{Gestion}
  \begin{itemize}
    \item CVS ne peut pas servir comme outil de mesure de
    productivit\'e, ou comme outil de planning.
  \end{itemize}
\end{slide}

\begin{slide}{Build}
  \begin{itemize}
    \item CVS n'est pas un outil de build. 
    \item Pour construire des fichiers de build, il faut les
    \'ecrire, ou utiliser d'autres outils (comme, par exemple,
    autoconf). 
    \item M\^eme dans le pr\'esence de ces fichiers, CVS ne peut
    pas faire un build. L'assurance que les sources marchent
    comme ils doivent reste avec les gens qui l'utilisent.
  \end{itemize}
\end{slide}

\overlays{5}{
\begin{slide}{Comment marche CVS?}
  
  \onlySlide*{1}{%
    \begin{figure}[ht!]
    \begin{center}
      \epsfig{file=ch02dia1.eps}
    \end{center}
    \caption{Serveur et clients}
    \end{figure}
    CVS est \`a la base une serveur des fichiers.

  }%
  \onlySlide*{2}{%
  \begin{figure}[ht!]
  \begin{center}
    \epsfig{file=ch02dia2.eps}
  \end{center}
  \caption{Un serveur de fichiers typique}
  \end{figure}
  }%
  \onlySlide*{3}{%
  \begin{figure}[ht!]
  \begin{center}
    \epsfig{file=ch02dia3.eps}
  \end{center}
  \caption{Lock/modify/unlock}
  \end{figure}
  }%
  \onlySlide*{4}{%
  \begin{figure}[ht!]
  \begin{center}
    \epsfig{file=ch02dia4.eps}
  \end{center}
  \caption{Lock/modify/merge 1}
  \end{figure}
  }%
  \onlySlide*{5}{%
  \begin{figure}[ht!]
  \begin{center}
    \epsfig{file=ch02dia5.eps}
  \end{center}
  \caption{Lock/modify/merge 2}
  \end{figure}
  }%

\end{slide}
}

%Introduction to CVS - checkout, modify, update, diff, commit. 
%Setting up the environment.

\begin{slide}{Introduction \`a CVS (finalement)}
  
  \begin{itemize}
    \item CVS est un outil de ligne de commande.
    \item il existe plusieurs outils graphique pour gerer des
    copies locales de CVS, mais ils utilisent tous l'outil ligne
    de commande \`a la base.
    \item Pour cette raison, c'est assez facile d'utiliser
    n'importe quel interface graphique d\`es qu'on connais bien
    l'outil ligne de commande.
  \end{itemize}
\end{slide}

\begin{slide}{Initialisation d'environement}
  \begin{itemize}
    \item Il faut dire \`a CVS ou est la r\'epositoire qu'on va
    utiliser. Ceci peut \^etre fait dans plusieurs facons - 
    \begin{itemize}
      \item export CVSROOT=location de repositoire
      \item cvs -d location de repositoire commande
      \item cvs commande dans une copie locale existante.
    \end{itemize}
    \item Le format d'un location d'un repositoire est 
      [\emph{protocole}:\emph{hostname}:]\emph{chemin sur serveur}
    \item Les protocoles possibles sont \textbf{pserver} ou
    \textbf{ext}. 
    \item Il y a aussi le possibilit\'e d'usage locale, et dans ce 
    cas l\`a on met ni protocole, ni hostname. 
  \end{itemize}
\end{slide}

\begin{slide}{T\'el\'echarger des sources}
  
  \begin{itemize}
    \item \textbf{cvs checkout \emph{module}}
    \item Apr\`es mettre en place un CVSROOT qui va bien, on peut
    checker out une copie locale des sources.
    \item Ceci fait des fichiers normaux dans le r\'ep\'ertoire
    courant, avec des fichiers CVS dans un r\'ep\'ertoire qui
    s'appele CVS.
  \end{itemize}
\end{slide}

\begin{slide}{Mettre \`a jour des fichiers}
  \begin{itemize}
    \item \textbf{cvs update}
    \item Dans le r\'ep\'ertoire courant, demande au serveur si
    il y a des fichiers plus r\'ecents \`a int\'egrer. Si c'est
    le cas, d\'escent les diff\'erences pour les merger
    localement.
    \item Les fichier modifier localement sont marqu\'e par M
    \item Les fichier mises \`a jour sont marqu\'e P ou U
    \item Les fichier avec des conflits sont marqu\'e C
  \end{itemize}
\end{slide}

\begin{slide}{Rajouter et effacer des fichiers}
  \begin{itemize}
    \item \textbf{cvs add, cvs remove}
    \item En CVS, on souviens de tout, meme la cr\'eation et
    effacement des fichiers. Si je veux effacer un fichier, je
    l'efface dans la copie locale, et en suite j'indique \`a CVS
    que c'est effac\'e en faissant un \emph{cvs remove}. 
    \item Pour rajouter une fichier, je le cr\'ee d'abord, et
    apr\`es je le passe sous la contr\^ole de CVS en faissant un
    \emph{cvs add}.
    \item Pendant un update, les fichiers rajouter sont marqu\'e
    A et les fichiers effac\'e sont marqu\'e D.
  \end{itemize}
\end{slide}

\begin{slide}{Envoyer nos changements au serveur}
  \begin{itemize}
    \item \textbf{cvs commit}
    \item Ce commande demande l'entr\'e d'une commentaire
    d\'ecrivant les changements comprises. C'est une bonne id\'ee
    d'en mettre.
    \item Si une ou plusieurs des fichiers qu'on veut committer
    n'est pas \`a jour, on a une message, et le commit ne passe
    pas.
  \end{itemize}
\end{slide}

\begin{slide}{CP1}
  Recuperer et travailler avec des sources
\end{slide}
%
% File status - cvs status, cvs diff
% Looking at logs - cvs log, cvs info
% Creating and resolving a conflict (merging)

\begin{slide}{Analyser l'\'etat d'un fichier}
  \begin{itemize}
    \item \textbf{cvs status}
    \item Information sur l'\'etat actuel du fichier, y compris:
    \begin{itemize}
      \item La version sur laquel le fichier est bas\'e
      \item La version le plus r\'ecent sur le serveur
      \item Si c'est modif\'e localement ou non
      \item Si le fichier est sur une branche ou un tag
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Vive la diff\'erence}
  \begin{itemize}
    \item \textbf{cvs diff}
    \item Visualise les diff\'erences entre les fichiers locaux
    et les versions sur le serveur.
    \item Ceci permet pour les utilisateurs avec acces lecture
    seule d'envoyer des fichier en format `patch' aux committeurs
    du module
    \item Il prend en argument des versions et/ou des dates, pour
    calculer (par exemple) la diff\'erence dans un projet entre
    minuit et midi un jour donn\'e, ou toutes les changements
    fait entre la version 1.24 et Vendredi 13.
  \end{itemize}
\end{slide}

\begin{slide}{Suivre des logs}
  \begin{itemize}
    \item \textbf{cvs log}
    \item Visualisation de l'historique des changements aux
    fichiers concern\'e.
    \item Les messages de log qu'on donne au commit sont tr\`es
    utile ici - ceci permet de localiser tr\`es rapidement la
    source de regressions, si les commantaires sont assez
    descriptives. 
    \item Si les commentaires sont (no comment), ben, ca sers \`a
    beaucoup moins, \`a part donner les dates des changements.
  \end{itemize}
\end{slide}

\begin{slide}{CP2}
  Suivre des sources
\end{slide}

\begin{slide}{Resolution des conflits}
  \begin{itemize}
    \item Si, quand on se met a jour, on voit des fichiers
    marqu\'e C, on a des conflits.
    \item Un conflit passe quand "patch" ne r\'eussi pas \`a
    int\'egrer des changements pr\'esent dans la refferentiel
    avec des changements pr\'esent localement.
    \item Ces conflits sont balis\'e par >>>>>>>>>>>,
    ============== et <<<<<<<<<<<<< dans le fichier locale.
    \item Si on a une conflit et on essaye de commit, on risque
    de mettre ces balises dans la referrentiel. C'est tr\`es
    important de resoudre les conflits avant committer.
  \end{itemize}
\end{slide}

\begin{slide}{CP3}
  Resolution des conflits
\end{slide}

% Creating a tag or branch
\begin{slide}{Cr\'eer des tags ou branches}
  \begin{itemize}
    \item \textbf{cvs tag [-b]}
    \item Tag (ou construit une branche) \`a partir du copie
    courant.
    \item une branche est un genre de tag sp\'eciale sur lequel
    on peut faire des changements
    \item Ceci permet le d\'eveloppement dans un seule
    repositoire de plusieurs versions au m\^eme temps.
  \end{itemize}
\end{slide}

%Changing tags/branches (update -r/-A)
\begin{slide}{Changer de vue dans une copie locale}
  \begin{itemize}
    \item \textbf{cvs update -r \emph{tag|branch|revision}}
    \item On peut changer de vue en passant un argument -r \`a
    update. Ceci prends comme argument le nom d'un revision, ou
    le nom symbolique d'un tag ou branche.
    \item On peut \'egalement changer le vue en utilisant un
    argument de date \emph{-D date}, ou en donnant l'argument
    \emph{-A} qui enl\`eve chaque tag collante pr\'esent
    localement.
  \end{itemize}
\end{slide}

\begin{slide}{CP4}
  Travailler avec des branches et des tags
\end{slide}

\begin{slide}{Initialiser un repositoire}
  \begin{itemize}
    \item \textbf{cvs init \emph{chemin d'acces}}
    \item Ce commande cr\'ee l'espace de serveur de CVS
    \item Dedans il y a des fichiers administratives pour g\`erer
    des genre de chose comme des modules, des actions \`a faire
    sur les commits, les utilisateurs en lecture seule, et
    d'autres.
    \item Pour un r\'epositoire locale, il y a rien d'autre \`a
    faire.
  \end{itemize}
\end{slide}

\begin{slide}{Importing sources}
  \begin{itemize}
    \item \textbf{cvs import \emph{rep sur serveur} \emph{vendeur} \emph{revision}}
    \item Import des sources dans le r\'epertoire courant dans le
    serveur. Les fichiers se retrouveraient dans le r\'epertoire
    sp\'ecifi\'e dans la r\'epositoire. Les deux tags \`a la fin
    ne sont pas habituellement tr\`es utile.
    \item Ceci nous permet de suite de faire un cvs checkout
    \emph{module} pour r\'ecup\'erer des sources sous la gestion
    de CVS.
  \end{itemize}
\end{slide}

\begin{slide}{CP5}
  Cr\'eer un referentiel, et importer des sources.
\end{slide}

%CVS best practices
\begin{slide}{Bonnes mani\`eres en CVS}
  \begin{itemize}
    \item Utiliser une copie locale par tache majeur. 
    \item Update r\'eguli\'erement - voir plusieurs fois par jour
    sur les projets actives
    \item Travailler toujours dans la copie locale - les
    modifications faites aux fichiers \`a l'ext\'erieur risquent
    d'etre perdu
    \item Commit assez reguli\`erement - sinon il y a plus de
    risque des probl\`emes de merge pour tout le monde dans le
    projet
    \item Ne partager pas des copie locales. Ceci risue
    d'entrainer beaucoup des probl\`emes.
  \end{itemize}
\end{slide}

\end{document}