DVCS : introduction, principe et bonnes pratiques

Historique

Trois générations de systèmes de contrôle de version.

Les bases des DVCS

Assez semblables aux outils de deuxième génération.

4 concepts en plus :

• clone : créer un nouveau dépôt en dupliquant un dépôt d'origine
• push : copier les changements du dépôt local vers un dépôt distant.
• pull : copier les changements d'un dépôt distant vers le dépôt local.
• les DAG : des arbres orientés acycliques pour gérer son flux de développement

Clone : créer un nouveau dépôt en dupliquant un dépôt d'origine

Deuxième génération (centralisé) :

Troisième génération (décentralisé) :

Push

Envoyer un jeu de modifications du dépôt local vers un dépôt distant

Les deux dépôts ne sont pas forcément identiques après cette opération.

Pull

Récupérer un jeu de modifications d'un dépôt distant vers le dépôt local

Synchro complète de deux instance => pull complet du dépôt distant + push complet du dépôt local

Les DAG

Deuxième génération (centralisé) :

Troisième génération (décentralisé) :

Avantages : copie privée du dépôt

Objectif : limiter le nombre d'opérations de synchronisation (comme pour le multi-thread)

Développeurs	1	4	10
Connections	0	6	45

Avantages : rapidité

Temps d'un commit sur l'arbre entier de Valgrind [1]

Avantages : multi-sites

Plus grande flexibilité dans la gestion des synchronisation entre plusieurs sites.

Avantages : répartition de charge

Permet d'alléger la criticité du dépôt central.

Autres avantages

• Mode non connecté
• Organisation flexible des processus de développement
• Fusion du code plus simple
• Sauvegarde implicite

Inconvénients

• Verrous
• Gestion des très grands dépôt
• Intégration aux autres outils des forges
• Suppressions définitives
• Administration (ACL, utilisateurs)
• Contrôle d'accès par répertoire
• Facilité d'utilisation
• IHM

Bonnes pratiques collectives

• Définir le processus de développement dès le début du projet
• Assurer la traçabilité des branches via un outil de gestion de tickets
• Compiler et tester le code automatiquement après chaque commit
• Utiliser des tags pour faciliter la navigation dans les versions

Bonnes pratiques individuelles

• Revue rapide (diff) avant chaque commit
• Revue rapide des travaux de l'équipe (chaque matin)
• Veiller à la logique des commits
• Commenter l'intérêt de chaque commit
• Conserver les branches de travail fonctionnelles
• Revue des opérations de merge automatique, avant le commit
• Eviter les suppressions définitives
• Ne pas commenter le code lui-même
• Eviter les verrous

Autres bonnes pratiques

• Garder le dépôt aussi petit que possible (plusieurs dépôts/projet)
• Ne stocker que les objets créés manuellement

Références