Outils pour utilisateurs

Outils du site


fossil

L'intérêt d'un gestionnaire de version pour un projet uni-personnel

FIXME: Article non finalisé.

Maintenant que GitHub (et donc git) est immensément populaire, l'article ci-dessous n'est plus très pertinent.

On a plus besoin d'expliquer l'intérêt d'un gestionnaire de contrôle de version (ou “contrôle de source”) pour les projets impliquant de nombreux développeurs. C'est le seul moyen de pouvoir s'y retrouver sur un projet: Pour savoir qui a fait quoi, sur quels fichiers, quand, pour pouvoir avoir les sources du projet à une date X, faire un retour-arrière, fusionner des modifications, etc. Il existe de nombreux logiciels de ce genre: RCS, CVS, subversion, Git, Mercurial, SourceSafe, ClearCase…

Utiliser ce genre de logiciel pour un projet uni-personnel peut sembler complètement overkill, mais cela a pourtant de nombreux avantages. Personnellement, j'utilise FOSSIL qui est léger à mettre en place (encore merci à Benoit M. qui m'a fait découvrir ce logiciel !).

FOSSIL inclue un gestionnaire de contrôle de version, un wiki, un blog, un système de bug-tracking et un mini-serveur web intégré.

Les bénéfices sont:

  • La sauvegarde du code source: Le simple fait de mettre vos sources dans le gestionnaire de version constitue une sauvegarde de fait. Sans compter que la base de source FOSSIL elle-même est un unique fichier facile à sauvegarder. En prime, vous avez la possibilité d'utiliser la synchronisation distante de FOSSIL, ce qui fait instantanément un backup sur d'autres machines (Fini le risque de perdre le travail car le serveur de sources ou votre poste de travail est mort).
  • Avoir à tout moment un code qui fonctionne: Fini le syndrome du “ça marchait hier”. Vous pouvez revenir à tout moment à une version que vous saviez fonctionnelle. Avouez que ça fait plus sérieux, non ?
  • Expérimenter sans peur: Vous pouvez bidouiller à mort, expérimenter sans risquer de tout casser: Il vous suffit de créer une branche et travailler dessus, sans perturber la branche principale (sur laquelle vous pouvez continuer à corriger des bugs, par exemple). Si votre modif vous convient, fusionnez avec la branche principale. Sinon, fermez votre branche.
  • Un meilleur passage de connaissance: La vie de votre projet et toutes les modifications sont archivées. C'est plus simple quand il faut passer le flambeau à quelqu'un d'autre: Il aura tout l'historique du projet, jusqu'à la date de modification de la moindre ligne de code.
  • Une meilleure traçabilité et une plus grande transparence: Une meilleure traçabilité vis-à-vis du client… mais aussi pour vous. Vous êtes capable de dire à quelle date a été livrée la fonctionnalité X ou à quelle date a été corrigé le bug Y. (En prime, vous avez la possibilité d'ouvrir le serveur web intégré à FOSSIL à d'autre pour qu'ils puissent le consulter).
  • Un meilleur suivi des incidents: Avec le bug-tracker intégré à FOSSIL, vous n'oublierez pas de corriger des bugs. Vous pouvez ou non l'ouvrir aux utilisateurs afin que quiconque puisse créer un ticket d'incident. Et on peut facilement faire un lien vers le commit quand le bug est réglé, ce qui améliore encore la traçabilité.
  • Travailler avec plus d'assurance: Si vous travaillez sur un serveur partagé avec d'autres, vous n'aurez plus à vous poser la question de savoir si un admin ou un autre développeur a touché par inadvertance à vos sources. Et ne rien perdre si l'admin fait une bourde (shit happens). Vous avez une copie locale de votre projet, et FOSSIL peut à tout moment vous montrer les différences avec ce qu'il y a sur le serveur.
  • Palier à votre mémoire défaillante: Vous avez sûrement déjà éprouvé ce sentiment de vide en reprenant un projet que vous n'avez pas touché depuis 2 ans: Oh mince, comment ça marchait, déjà ? Votre base de source est la mémoire de votre projet. Vous savez sur quoi vous avez travaillé et quand. Vous pouvez retrouver comment vous avez corrigé un bug précis. Le wiki intégré aide aussi, si vous avez documenté votre projet.
  • Capitaliser pour des projets futurs: Votre base de source est la mémoire de votre travail. Vous pourrez vous y référer plus tard. Comment aviez vous implémenté la fonctionnalité X ? Comment avez-vous corrigé ce fichu bug ?
  • Travailler offline: Pour peu que vous ayez le reste de l'environnement (environnement de développement, compilateur, base de données, serveur…), vous pouvez emporter votre base FOSSIL pour travailler sur le projet offline. Quand vous revenez, resynchronisez votre base et toutes vos modifs sont répercutées (commits, wiki, tickets…).
  • Étendre à d'autres développeurs: Il est facile d'ouvrir FOSSIL à d'autres développeurs (FOSSIL a une gestion des droits intégrée). Et oui - le travail offline est également possible pour de multiples utilisateurs. FOSSIL gère aussi les merge.
  • Les cadeaux bonus de FOSSIL:
    • Le wiki intégré est utile pour documenter le projet. On peut faire facilement des liens vers les tickets d'incident ou les commits.
    • Le blog est utile pour communiquer, soit avec le client ou les utilisateurs sur les nouvelles fonctionnalités, soit avec le reste de l'équipe du projet.

En tant que développeur, vous devriez vraiment vous y mettre, même pour un petit projet perso. Avec FOSSIL aucune excuse: Il est vraiment facile à mettre en place. (Dis Benoît, quand est-ce que tu fais ton tuto sur FOSSIL ? ;-) )

Astuce: Mettez toute l'arborescence de votre site web sous FOSSIL. Vous pourrez traquer les modifications (même effectuées par l'admin du serveur). Et vous pourrez facilement faire un retour-arrière en cas de bourde.

Pourquoi FOSSIL ?

Il existe de nombreux gestionnaires de version. Pourquoi FOSSIL ?

  • Il est gratuit et opensource.
  • Son format de sauvegarde est ouvert et documenté.
  • Très robuste (utilise SQLite). Jamais on a vu une base FOSSIL corrompue. (Les utilisateurs de SourceSafe ou ClearCase ne peuvent pas en dire autant.)
  • Il fonctionne sous Windows, Linux et MacOSX. Et vous pouvez utiliser telle quelle votre base de source sous ces systèmes.
  • Tout tient en un seul exécutable: Vous n'avez pas un gros service à installer, et vous pouvez à tout moment le déplacer sur une autre machine.
  • Simple: Il est facile à utiliser. Simplicité = meilleure maîtrise. (Rien de pire qu'un bon outils mal utilisé - j'ai vu des horreurs sous ClearCase.)
  • FOSSIL contient base de source + wiki + blog + bugtracker.
  • Tout cela tient en un seul fichier. Facile à sauvegarder et déplacer.
  • Il peut fonctionner de manière distribuée (avec synchro automatique ou manuelle). La synchro prend en compte les sources, le wiki, le blog et les tickets. Elle utilise HTTP et peut donc traverser la majorité des firewalls. Ah… et FOSSIL peut fonctionner en tant que CGI, ce qui permet de l'intégrer à un serveur web.

Que tracer ?

Tracer vos sources est bien, mais non suffisant. Vous devriez tracer aussi:

  • Les documents statiques (html, css et autres).
  • Les images (on modifie aussi les images)
  • La base de données: Vous devriez archiver les modifications apportées à la base de données.
  • La configuration: Vous pouvez archiver votre apache2.conf, php.ini et autres fichiers de config (FOSSIL suit les liens symboliques.). Pratique pour revenir en arrière quand on merde un fichier de config.

Discussion

Benoit M, 2011/03/14 16:36

Mon tuto sur fossil n’est pas encore prioritaire (beaucoup de choses en cours) mais il viendra. Je te préviens évidemment !

Benoit M, 2011/03/14 16:41

Quand même une remarque :

« Sinon, jetez votre branche. »

Non, on peut clore une « feuille » pour dire qu'elle n'aura pas de descendants, mais on ne jette rien. Tout reste archivé, le principe c'est justement de fossiliser tout.

Sébastien SAUVAGE, 2011/03/14 16:42

Exact ! Je corrige.

Rolinh, 2011/03/14 22:59

Cela fait plusieurs mois que j'utilise mercurial pour mes petits projets personnels et pour des travaux pratiques (université). Et c'est vrai que cela a de nombreux avantages! Notamment, je travaille souvent sur deux machines différentes et donc, de cette façon, je suis sûr de toujours travailler sur la dernière version des mes différents projets. Difficile de s'en passer une fois habitué…

lobotomised, 2011/03/15 09:13

A la fin de ton article - très intéressant, merci - tu parle qu'on peut aussi versionner une base de donnée. Il me semble que mysql, ou au moins certain de ses moteurs (innodb) par exemple supporte assez mal d'être sauvegarder seulement via ses fichiers. Enfin surtout quand on réimporte les tables. Le versionnage fait le même genre de sauvegarde/restauration. Donc je suppose que ce n'est pas forcément une très bonne idée

Sébastien SAUVAGE, 2011/03/15 09:58

Il faut tracer les scripts de modification de structure appliqués à la base, ça me semble normal. Mais il serait aussi intéressant de sortir un dump de la structure de la base, histoire de connaître la structure de la base à une date X.

Pour la base de données, il n'y a pas de solution idéale.

Quand je faisais de l'intégration, on gardait dans le gestionnaire de source tous les scripts des développeurs appliqués à la base pour traçabilité, et après chaque grosse livraison on extrayait le script de structure de la base entière pour garder une trace. Comme ça, avec un diff on pouvait voir toutes les modifs apportées (structure, procédures stockées, etc.) entre deux livraisons.

Le but n'est pas vraiment de pouvoir reconstruire la base à partir des scripts archivés, mais de tracer les modifications.

Mais j'admets que c'est loin d'être l'idéal.

lobotomised, 2011/03/15 10:09

C'est bien ce que je pensais. C'était juste que ta formulation peut amener quelqu'un à se dire qu'il va faire des sauvegardes de sa base de données avec ça. Mauvaise idée !

Sébastien SAUVAGE, 2011/03/15 10:14

C'est pour cela que j'ai mentionné ”Vous devriez archiver les modifications apportées à la base de données.”. C'est vraiment juste pour tracer les modifications apportées, pas pour sauvegarder les données.

Benoit, 2011/03/15 13:25

Toujours est-il que l'on peut pseudo-versionner une base de données SQLite en utilisant une simple commande « .dump » avec le shell SQLite et en versionnant le résultat.

JLG, 2011/04/14 13:26

Bonjour, Aprés avoir lu ton article, FOSSIL m'a convaincu. Mais je n'arrive pas à utiliser le wiki, même après avoir lu 20 fois la page : http://www.fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki Pourrais-tu me donner quelques conseils ? Cordialement. JLG

Sébastien SAUVAGE, 2011/04/29 11:02

Le wiki est très basique.

Créer une page: Dans le menu, clic sur “Wiki”, puis “Create a new wiki page.”.

Modifier une page existante: Clic sur une des pages dans “List of All Wiki Pages” et clic ensuite sur “Edit”.

Faire un lien vers une page: [Nom de la page]

La syntaxe wiki est limitée, mais tu peux utiliser des balises HTML si tu veux.

Nano, 2011/09/24 16:16

Salut, Serait-il possible d'avoir un lien vers un tutoriel français, svp? (Benoit M.??) Merci

vince, 2011/11/08 08:04

Salut,

je viens de découvrir ce petit bijou, et je vous ai fait aussitôt un tutorial, que vous pouvez aussi télécharger à cette adresse (qui est d'ailleurs plus lisible) : http://vince38.perso.sfr.fr/fossil.odt

Tutorial pour démarrer rapidement avec fossil

Tout d'abord, qu'est-ce qu’un repository ou référentiel (que l'on peut aussi traduire par “stockage”)? C'est simplement une base de données avec l'historique complet du projet. Lorsque l'on fait un commit, fossil compare les fichiers locaux avec la dernière version contenue dans cet historique. Si des fichiers ont été modifiés depuis la dernière version enregistrée, une nouvelle version est créée dans la base de données et les fichiers modifiés y sont rajoutés.

1) Création du référentiel

1-a) Nouveau référentiel

Créer un nouveau référentiel :

		fossil init Nom_de_fichier_du_référentiel
	ou (commande strictement identique)
		fossil new Nom_de_fichier_du_référentiel

Par défaut, l'admin du référentiel est l'utilisateur courant et un mot de passe est généré :

project-id: 819c8b5d5c2bb57888a79f8aec3a7afb6d4369df
server-id:  295e041b4ff4229ee63827cde75585317bae85ff
admin-user: vince (initial password is "7d59d1")

Pour utiliser un autre nom d'admin que le nom de l'utilisateur courant :

	fossil init -A username Nom_de_fichier_du_référentiel

1-b) Dupliquer un référentiel existant

fossil clone référentiel_à_cloner    nom_du_nouveau_référentiel
fossil clone http://www.fossil-scm.org/mon_référentiel    nom_du_nouveau_référentiel

2) Ouverture et configuration du référentiel

Après avoir créé le référentiel, il faut l'ouvrir :

fossil open Nom_de_fichier_du_référentiel

On peut tout faire en ligne de commande, mais on peut aussi faire beaucoup de choses par l'interface web.

Pour lancer l'interface web :

fossil ui

Configuration depuis l'interface web :

-Attention, tant qu'on n'a pas fait le premier commit, l'onglet “Files” fait planter fossil.

-Décocher l'option “Use Universal Coordinated Time” dans la partie timeline

pour que fossil utilise l'heure de votre pc et pas celle de Greenwich.

-Pour éviter que fossil râle quand des fichiers sous Windows ont des CR/NL en fin de ligne, il faut mettre * à crnl-glob.

-Pour les utilisateurs de Windows, décocher l'option case-sensitive.

-Dans la case ignore-glob, indiquer la liste des fichiers à ignorer lors d'un add

(n'est pas utilisé lors d'un addremove, ce qui est bien dommage. Il y a quand même l'option –ignore).

Cette liste est sensible à la casse, même si on a décoché l'option case-sensitive.

-Indiquer un éditeur de texte dans la case editor pour rajouter plus facilement un commentaire lors du commit.


Ajout de fichiers ou de répertoire (rajoute aussi les sous-dossiers) :

fossil add fichier1 fichier2
fossil add répertoire

Je n'ai pas trouvé comment rajouter un dossier sans ses sous-répertoires, si quelqu'un a la solution, ça m'intéresse…

Supprimer des fichiers ou des dossiers (pour avoir la liste des fichiers/dossiers, utiliser la commande ls) :

fossil rm répertoire
ou
fossil delete répertoire

3) Utilisation du référentiel

Jusqu'à maintenant, nous n'avons fait que configurer le référentiel, aucun fichier n'a été copié. Pour copier les fichiers, il faut utiliser la commande commit :

fossil commit
ou
fossil ci

Il faut mettre un commentaire (plus facile si vous indiquez un éditeur de texte dans les settings) et c'est tout! Vous pouvez maintenant modifier vos fichiers.

Pour voir quels fichiers ont été modifiés depuis le dernier commit :

fossil changes

Pour voir précisément ce qui a été modifié dans les fichiers :

fossil diff

Quand vous voulez enregistrer les modifications de vos fichiers, il suffit de refaire un commit. Si des nouveaux fichiers ont été rajoutés dans vos dossiers, ils ne sont pas pris en compte. Il faut refaire un “fossil add répertoire” pour que les nouveaux fichiers soient rajoutés.

La commande addremove rajoute automatiquement les nouveaux fichiers et enlève les fichiers du référentiel qui ont été supprimés. En gros, elle fait une synchro entre vos fichiers et le référentiel. Le problème, c'est que cette commande fait la synchro depuis le local-root (le répertoire de travail) et du coup, elle inclue fossil.exe, le fichier de base de données et tout ce qu'il y a dans le local-root, ce qui n'est pas cool! Je n'ai pas trouvé comment modifier le local-root, si quelqu'un a la solution, ça m'intéresse aussi!

4) Autres commandes

Voir les modifications par ordre chronologique, avec les commentaires, par qui ont été faites les modifs et sur quelle branche:

fossil timeline

Voir la liste des fichiers du référentiel :

fossil ls

Vérifier si des fichiers ont été modifiés ou pas dans la dernière version du référentiel:

fossil co --latest
ou
fossil checkout --latest

Avec l'option –force, la version du référentiel est copiée sur le système de fichier local. Cela supprime toutes les modifications effectuées depuis le dernier commit:

fossil co --latest --force

C'est ce qu'il se passe aussi quand on ouvre un référentiel, la dernière version de ce référentiel est restaurée.

Clore le référentiel :

fossil close

Et encore plein d'autres commandes à explorer avec l'aide, qui est très bien faite et très exhaustive :

fossil help

5) Plein d'autres fonctionnalités

-Utilisation de fossil comme script cgi

-Importer un référentiel depuis git

-Exporter une version dans un fichier tarball ou zip

-Un gestionnaire d'incident

-Un wiki

-Peut être lancé en temps que service sous Windows

KB, 2012/01/10 16:57

Merci pour ce tuto bien fait pour démarrer.

Je n'ai personnellement pas été convaincu par Fossil pour le moment. Je ne suis pas très friand d'un client en ligne de commande. L'interface web est sympathique mais le fait de ne pas pouvoir ajouter / supprimer / commiter directement depuis l'interface fait défaut selon moi. Pratique en consultation, pas très pratique à l'utilisation.

Dans le cas du déplacement de fichiers cela devient l'enfer à gérer (ajout / suppression de fichiers) Si on fait un ajout à la racine de plusieurs fichier on a le choix entre faire un add suivi de l'ensemble des noms de fichiers ou un add . qui ajoute également le fichier fossil.exe!

Reste le Wiki associé qui peut être pratique.

Je vais continuer mes essais et je reviendrai ici si je change d'opinion :)

Chimarro, 2012/01/14 17:27

il existe plusieurs gui pour fossil, jurassic-fossil, fuel-scm, SharpFossil(win), QLFossil(mac). Jurrasic est trop minimaliste. Fuel est soit-disant compatible linux, mais comme je suis allergique a wine, je ne garderai pas cette solution. Les autres ne sont pas compatible avec linusque.

Sébastien SAUVAGE, 2012/01/30 15:51

Merci pour ces infos, ça sera utile !

vince, 2012/04/14 09:46

Il y a la version 1.22 qui vient de sortir.

Le bug de l'onglet “Files” qui faisait planter fossil tant qu'on n'avait pas fait le premier commit est résolu.

De plus, je viens de comprendre un truc important que l'on m'a expliqué en discutant sur la mailing-list de fossil.

Cela résout le problème de la commande addremove qui rajoute tous les fichiers du répertoire de travail avec fossil.exe inclus et ça résout aussi le problème de mister “kb” avec le add . qui ajoute également le fichier fossil.exe!

En fait, la racine du repository se trouve dans le répertoire de travail.

Donc, pour bien faire, il faut que le répertoire de travail ne soit pas le même répertoire où se situe fossil.exe.

Par exemple, les fichiers locaux sont dans : c:\mes_projets

Fossil est dans c:\mes_programmes\fossil.exe

Le repository est dans c:\mes_programmes\test.fossil

Il faut se placer dans le répertoire “mes_projets” :

    cd c:\mes_projets

Et il faut lancer les commandes comme suit :

    c:\mes_programmes\fossil.exe open c:\mes_programmes\test.fossil
    c:\mes_programmes\fossil.exe add *

Comme cela, seuls les fichiers de c:\mes_projets\ sont ajoutés Et la commande addremove fonctionne maitenant correctement :

    c:\mes_programmes\fossil.exe addremove
    DELETED  dir1/P1050865.JPG
    DELETED  dir1/P1050869.JPG
    DELETED  dir1/P1050913.JPG
    DELETED  dir1/Thumbs.db
    DELETED  dir1/dir3/P1060009.JPG
    DELETED  dir1/dir3/P1060010.JPG
    DELETED  dir2/DSC00816.JPG
    DELETED  dir2/DSC00817.JPG
    DELETED  dir2/DSC00818.JPG
    DELETED  dir2/DSC00819.JPG
    added 0 files, deleted 10 files
Jerry Wham, 2017/04/21 08:27

Il y a aussi la possibilité de mettre fossil.exe dans un sous-dossier du dossier programme et de modifier la variable $PATH de windows pour que la commande `fossil` soit prise en compte dans l'invite de commande.

Ensuite, il suffit d'utiliser le paramètre `settings' avec l'option `ignore-glob` pour spécifier les fichiers que l'on ne veut pas voir apparaître dans les commit (un peu à la manière du fichier .gitignore).

Par exemple : <pre>fossil settings ignore-glob “*.pdf,sess_*,*.DS_Store,*.gitignore,*.exe” –global</pre>

Entrer votre commentaire. La syntaxe wiki est autorisée:
   ____   __ __   _  __   ___    __  ___
  / __/  / //_/  / |/ /  / _ \  /  |/  /
 _\ \   / ,<    /    /  / , _/ / /|_/ / 
/___/  /_/|_|  /_/|_/  /_/|_| /_/  /_/
 
fossil.txt · Dernière modification: 2016/11/22 16:01 par sebsauvage