Qt : /* Exemples de VCS */

2010-12-10T15:06:53Z

Exemples de VCS

← Version précédente		Version du 10 décembre 2010 à 15:06
Ligne 10 :		Ligne 10 :
	* [[CVS]], assez vieux et peu performant		* [[CVS]], assez vieux et peu performant
	* [[SVN]], très répandu, basé sur une architecture client/serveur		* [[SVN]], très répandu, basé sur une architecture client/serveur
	* [[Git]], qui gagne en importance ; basé sur une architecture très distribuée, il est utilisé pour [[Frankiz]].		* [[Git]], qui gagne en importance ; basé sur une architecture très distribuée, il est utilisé pour Frankiz.

	== Concepts ==		== Concepts ==

Xelnor : Doc sur les VCS, version basique

2009-12-05T16:31:51Z

Doc sur les VCS, version basique

Nouvelle page

== Version Control System ==

Un ''VCS'' (ou ''système de contrôle de version'') est un outil de suivi de l'évolution d'un projet.

L'objectif d'un VCS est de faciliter le travail collaboratif sur un projet, et de maintenir un excellent suivi de l'historique du projet.

=== Exemples de VCS ===
Il existe de nombreux VCS, le BR a utilisé ou utilise encore les suivants :

* [[CVS]], assez vieux et peu performant
* [[SVN]], très répandu, basé sur une architecture client/serveur
* [[Git]], qui gagne en importance ; basé sur une architecture très distribuée, il est utilisé pour [[Frankiz]].

== Concepts ==

=== Bases ===
Un VCS se compose :
* D'un '''dépôt''' : l'endroit où est stocké l'ensemble de l'historique du projet (il peut y en avoir plusieurs dans le cas de [[Git]] )
* De '''copies de travail''' (ou '''checkouts''') : En général une par développeur, il s'agit grosso modo d'un export du dépôt, qui stocke notamment (dans un dossier caché) la version ''dépôt'' des fichiers

=== Commits ===
Lorsque l'on développe, on va récupérer une copie du dépôt, puis effectuer ses modifications et les tester. Une fois que les changements sont corrects, on va réaliser ce que l'on appelle un '''commit''' : il s'agit d'envoyer au dépôt les modifications que l'on a effectuées, sous forme de différences par rapport au fichier d'origine. On accompagne la chose d'un message décrivant ce qui a été fait (par exemple, ''fix bug in XXX'', ''add link for YYY'', ...).

Cela permet de disposer de l'historique des modifications effectuées sur le projet, et de savoir qui a fait quoi :)

En général, lors d'un commit, un mail résumant les modifications effectuées est envoyé à l'ensemble des développeurs du projet.

Avant d'effectuer des modifications, il convient de mettre à jour sa copie locale : ceci limite le risque de conflit à résoudre ''a posteriori''.

=== Merge ===
Si l'on a effectué des modifications et qu'un autre utilisateur a ''committé'' en parallèle, deux situations peuvent se produire :
* Les modifications locales et celles de l'autre développeur concernent des fichiers différents : dans ce cas, le VCS va automatiquement fusionner les modifications (i.e appliquer les modifications de l'autre développeur)
* Les deux développeurs ont modifié les mêmes lignes d'un même fichier : on parle de '''conflit'''. Dans ce cas, le VCS le signale et laisse au développeur le soin de fusionner correctement les modifications (on parle de '''merge''').

=== Branches ===
Lorsque les changements à effectuer sont importants et occupent une place certaine, on crée une '''branche''' : on part de l'état du projet à l'instant t0, et on diverge du développement standard en ajoutant des modifications variées (généralement pour ajouter une fonctionnalité innovante mais qui impose de lours remaniements du code).

Une fois cette fonctionnalité achevée, on va '''merger''' la branche divergente avec la branche principale : il s'agit d'appliquer les changements de la branche divergente à la branche principale. En général, dans le procédé, le VCS commence par appliquer le plus grand nombre possible de commits de la branche divergente à la branche principale ; à chaque fois qu'un conflit se présente, on demande à l'utilisateur de résoudre. Une fois le '''merge''' terminé, on commite les modifications effectuées.

En général, un projet contient les branches suivantes :
* ''master'' (ou ''trunk'') : là où s'effectue le développement actif,
* ''prod'' : la version de production, sur laquelle on reportera les commits importants (en général, ceux qui résolvent des failles de sécurité)

=== Tags ===

Lorsque l'on considère qu'il est temps de sortir une nouvelle version, on réalise un '''tag''' : il s'agit d'une capture de l'état du dépôt lors de cette version. Cela permet facilement de suivre l'évolution depuis la dernière ''release'', par exemple.

== Processus de travail ==

Le processus est souvent le suivant :
# Le développeur récupère une copie de travail
# Il fait des modifications, et les teste
# Il envoie un commit
# Un autre développeur fait des modifications
# Le développeur met à jour sa copie de travail (y propageant ainsi les modifications effectuées par les autres développeurs)
# Il fait à nouveau des modifications, les teste, puis committe.

Et ainsi de suite.

== Règles de bon usage ==

Quelques règles sont à respecter dans un processus de développement collaboratif :
* Les commits doivent être atomiques : un commit résoud un bug, ajoute une seule fonctionnalité, ... (pas de ''fix typo, fix bug, add XXX'')
* Les branches doivent rester opérationnelles : sauf cas exceptionnels, pas de régression dans un commit (si ça marchait avant, ça doit marcher après)
* On doit accompagner chaque commit d'un message décrivant son effet (pas de ''fix bug'' mais ''Fix problem in module XXX : ...'').
* Si un commit résoud un bug indiqué dans le gestionnaire de bugs (Bugzilla, Flyspray, Trac), l'indiquer dans le message : ''Fix bug #42666'' ; en effet, il arrive souvent que ce genre de message ferme automatiquement la tâche en la reliant au commit

VCS - Historique des versions

Qt : /* Exemples de VCS */

Xelnor : Doc sur les VCS, version basique

Qt : /* Exemples de VCS */

Xelnor : Doc sur les VCS, version basique