momo54/Dice — Issue #1: Mvn Problem
Author: momo54
Created: 2011-12-01 05:59:30+00:00
State: open

mvn install does not run smoothly

Lundi 20 Octobre 2008 14h-18h.

Composition des binomes (à peu près au hasard ;):
|| border=1
|| Jonathan Atton || Mirko Bucci ||
|| Walser Benoit || Claude Tompess ||
|| Martinet Yannick || Grujic Misa ||
|| Payan Baptiste || Jessica Ecker ||
|| Martin GrandColas || Stéphane Virte ||
|| Benoit Thevent || Ricardo Ferreira Gonzales ||
|| Rao Sebastien || Bastien Triolet ||
|| Guo Ying || Josselin Pierre ||
|| Jie Chen || Paul Masson ||
|| Matthieu Chaffote || Davy Claisse ||
|| Marco Soares Carvalho || Jean Chistophe Mayan ||
|| Bruno Andriamiarina || Matthieu Arnaud ||
|| Wang Wei || Djellab Lyes ||
|| Bertozzi J. || Tounsi M. ||

! Objectifs

L'objectif du TP est de comprendre le mode de fonctionnement des DVCS (Distributed Version Control System) et de situer
les éventuelles faiblesses par rapport au VCS centralisés (si il y en a...)

Les Version Control System classiques souffrent de plusieurs défauts montrés en cours:
# Architecture centralisée
## pannes du serveur
## performances générale du serveur pour les développeurs éloignés
# Gestion difficile des branches et notamment des fusions à répétition des branches
## problème des ancêtres commun multiples, des criss-cross merge...
# Problèmes des droits d'accès (besoin d'un compte sur un serveur commun pour coopérer)
# Accès à toutes les fonctions d'un VCS sans accès au serveur: travail offline.

! Pré-requis

* Mercurial doit être installé :
[@
sudo apt-get install rcs
sudo apt-get install mercurial
@]

(rcs est installé pour le merge...)

[[http://www.selenic.com/mercurial|Mercurial (Hg)]] est un DVCS écrit en python. Il est un peu plus
facile à aborder que Git mais repose sur les mêmes concepts. Il a quelques avantages sur Git:
# Mieux intégré aujourd'hui avec eclipse, netbean...
# peut-être plus portable que Git (mais ça se discute)
# Prise en main plus facile.

D'un autre coté, Git me semble plus rapide et réagit mieux que Hg dans certaine situation délicate de merge.
Enfin bon, pour ce genre de considérations voir les pages respectives de [[http://en.wikipedia.org/wiki/Git_(software)|Git]] et [[http://en.wikipedia.org /wiki/Mercurial_(software)|Mercurial]] sur [[http://www.wikipedia.org|Wikipedia]]. IMHO, Ces deux logiciels sont tous deux excellent et gèrent l'un comme l'autre des très gros logiciels.

* La documentation de Hg est indispensable (et très bien écrite) [[http://hgbook.red-bean.com/hgbook.html|Hg Doc]]. Si vous voulez gagner du temps, mettez un lien dessus dans votre "bookmark toolbar".
! DVCS principle

Un DVCS peut fonctionner de la même manière qu'un VCS, mais cela ne présente pas beaucoup d'intérêt.
Le modèle original de coopération que propose un DVCS est le suivant:
Attach:dvcsprinciple.png

* PM. a un logiciel "ECC08" stocké dans ~/ECC08. Il l'a passé sous le controle d'un DVCS, il a créé un "repository" local, souvent dans le même repertoire que le logiciel en question.
** sous mercurial, il a fait un "hg init" dans le répertoire principal, cela à pour effet de créer un "repository" local.
** puis il a fixé les fichier à ignorer (.hgignore)
** puis il a ajouté (ou tracké) les fichiers à gérer : "hg add *"
** Enfin il fait le "commit initial" : hg commit -m "commit initial".
* Il veut maintenant coopérer avec GO. Pour cela il crée un deuxième repository destiné au public en '''clonant''' le premier. Ce deuxième repository est placé sur un serveur capable d'être accédé par GO., dans cet exemple, le serveur web du LORIA. PM., peut créer autant de repository public qu'il le souhaite et les placer ou ça lui chante.
** PM. accède en écriture à ce repository en SSH.
** Ce même repository est accessible en lecture pour les autres à l'addresse : http://www.loria.ff/ECC08. PM. avertit GO. de la disponibilité de ce repository par mail.
* GO. récupère ECC08 en clonant à son tour. Cela lui crée un repository privé sur sa machine personnelle.
** hg clone http://www.loria.fd/ECC08. Il peut alors faire des modifications en local.
* GO. veut renvoyer ses modifications à PM., il crée à son tour un repository public en clonant son espace privé et avertit PM. de la disponibilité de ce repository.
* PM. va alors fusionner les modifications de gérald par '''pull http://www.loria.fr/~oster/CCE08''' suivi éventuellement d'un merge (certain DVCS lance le merge automatiquement, d'autres non...)

A ce stade, la coopération est établie.
* Toute modification ultérieure suis un cycle de push/pull
* Si PM. fait des modifs, il les rend publiques en faisant un '''push''' sur http://www.loria.fr/~molli/ECC08.
* PM. intègre les modifs de GO. à tout moment en faisant un '''pull''' sur http://www.loria.fr/~oster/CCE08.

Le modèle de coopération est donc basé sur 3 primitives : '''push''', '''pull''', '''clone'''. Le modèle fonctionne bien si le merge est efficace.

! Exercice

* Le programme '''dice''' est maintenant fournit sous forme d'un dépôt Mercurial (Hg) à l'adresse suivante [@ static-http://www.loria.fr/~molli/hg/dice-0.0.1-SNAPSHOT @]
* Vous devez dans un premier temps vous familiariser avec Mercurial et arriver à exécuter le scénario ci-dessus avec un autre de groupe de TP.
* Chaque groupe doit donc dans un premier temps récupérer en local le logiciel Dice:
[@
hg clone static-http://www.loria.fr/~molli/hg/dice-0.0.1-SNAPSHOT
@]

* Cela va créer un dépôt privé chez chaque groupe
** faites un [@ mvn install @] pour vérifier que tout va bien.
* Ensuite, il faut examiner les différentes commandes Hg:
[@
Hg help
Hg log
hg status
hg view
hg diff
hg revert
@]

* Faites une modification (par exemple modifiez le readme), et regardez à nouveau les commandes précédentes.
* Créez un fichier "INSTALL" et ajoutez le comme fichier suivi (hg add INSTALL)
* regardez à nouveau les commandes précédentes.
* Commitez ce que vous venez de faire [@ hg commit -m "yo" @]
* regardez à nouveau les commandes précédentes. Vous devez bien comprendre ce qu'affiche [@ hg view @].

* Chaque groupe doit créer maintenant un dépôt "public" en clonant celui qui vient d'être créé,
** [@ cd /tmp; hg clone ~/dice-0.0.1-SNAPSHOT @]. On crée ce dépôt public dans le tmp juste pour les
besoins de la manipulation. Il faudrait bien sur cloner sur un endroit accessible depuis l'extérieur.
* [@ cd /tmp/dice-0.0.1-SNAPSHOT ; hg serve @]. Cette commande lance un serveur web et rend le dépôt Mercurial accessible par http. Vérifiez avec un accès [http://localhost:8000]. Tentez vous-même depuis un endroit approprié un [@ hg clone http://localhost:8000 @].
* Chaque groupe peut désormais faire un '''pull''' du dépot voisin.
* Faites maintenant les modifications de votre choix, rendez les publiques en les poussant ('''push''') dans votre dépôt public et ensuite fusionnez avec les modifications des autres.
* A ce stade, vous pouvez essayez avec tous les groupes voisins.

! Exercice

Maintenant que vous avez compris les grands principe des DVCS, il faut mieux connaître le comportement de Hg en cas de conflits.
Voici un script permettant de d'exécuter automatiquement des scenarii:

[@
#!/bin/bash
export HGMERGE=merge
rm -rf hg.cc.simple
mkdir hg.cc.simple
cd hg.cc.simple
mkdir s1
cd s1
hg init
echo -e '1\n2\n3\n4\n5\n' > foo.txt
hg add foo.txt
hg commit -m "init"
cd ..

hg clone s1 s2
hg clone s1 s3

cd s2
echo -e "3i\nY\n.\nw\nq\n" | ed foo.txt
hg commit -m "Y"
cd ../s3
echo -e "3i\nX\n.\nw\nq\n" | ed foo.txt
hg commit -m "X"

cd ../s2
hg pull ../s3
hg -y merge
echo -e '1\n2\nY\nX\n3\n4\n5\n' > foo.txt
hg commit -m "YX"

cd ../s3
hg pull ../s2
hg -y merge
echo -e '1\n2\nX\nY\n3\n4\n5\n' > foo.txt
hg commit -m "XY"
@]

En vous inspirant de ce script, écrivez les scripts permettant de connaître le comportement de Mercurial dans les situations suivantes:
|| border=1
|| hginsinsid.sh|| Insert/Insert à la même position avec le même contenu... ||
|| hginsins.sh|| Insert/Insert à la même position avec un contenu différent... ||
|| hginsdel.sh|| Insert/delete à la même position ||
|| hgmkfmkf.sh|| mkfile/mkfile avec le même nom et des contenus différents ||
|| hgmkdmkd.sh|| mkdir/mkdir avec le même nom et des contenus différents ||
|| hgmkdmkf.sh|| mkdir/mkfile avec le même nom ||
|| hgrmins.sh || rmfile("a.txt")/insert("a.txt",something) ||
|| hgrmdins.sh|| rmdir(/)/Insert(/a.txt), destruction du répertoire parent avec une modification concurrente à l'intérieur... ||
|| hgmvmv.sh || rename(/a.txt,/b.txt)/rename(/a.txt,/c.txt) (use hg rename to do that...) ||

* Faites un fichier '''result.txt''' montrant l'état final produit par l'exécution de chaque script.

! Exercice

J'ai écrit un script qui produit la sortie '''hg view''' suivante:

Attach:hg.many.png

# écrivez un script '''hg.many.sh''' produisant la même sortie.
! Rendu et notations

# Faites un fichier README.txt à la racine de votre projet.
## Mettez vos noms dedans et éventuellement, toutes remarques que vous voulez me faire parvenir
## Créez une archive tpdvcs1.zip
# uploadez l'archive sur la plateforme Arche http://arche.uhp-nancy.fr/
## Le module [[http://arche.uhp-nancy.fr/index_esup.php?id=2762|ECC]] est créé. Normalement, les étudiants du Master2 Info IL+RS ont les droits d'accès positionnés.

# Je dois pouvoir effectuer l'action suivante:
[@
$ unzip tpdvcs1.zip
$ bash hginsins.sh
$...
@]