Pourquoi un système de gestion de version ?

En fait la première question pourrait plutôt être : pourquoi donc utiliser un système de gestion de version (« version control system » en anglais, ou VCS) ? Regardez comment les codes sources sont gérés dans les paquets Debian. Tout d'abord, il y a le code source amont, souvent maintenu par quelqu'un d'autre. L'auteur amont a son propre fil de développement, et publie les sources au moyen d'instantanés (« snapshot », généralement appelés publications : « releases », ou versions du programme).

Le responsable Debian ajoute ses propres modifications, menant à sa propre version du paquet amont. L'ensemble des différences entre ces deux versions termine finalement dans les fichiers Debian .diff.gz, et cet ensemble de correctifs est généralement applicable aux versions amont suivantes, afin d'obtenir les « versions Debian ».

La manière évidente de s'occuper des mises à niveaux et modifications des sources est donc d'utiliser des copies locales, des correctifs, différents utilitaires de gestion de correctifs et des scripts pour automatiser le tout, comme par exemple uupdate. Cependant, cela devient souvent sale et pénible, sans laisser la possibilité de revenir en arrière sur les modifications éventuellement faites par erreur.

Dans ce cas, le système Subversion peut être utilisé pour se simplifier la tâche. Il réalise la même chose que ce que vous feriez vous-même, tout en conservant son propre historique (un dépôt). Il conserve les fils de développement amont et les sources Debian, en les gardant dans des répertoires différents (des branches différentes). Les branches sont connectées en interne (le VCS « connaît » l'historique des fichiers et suit la trace des différences entre les versions amont et Debian). Quand une nouvelle version amont est installée, les différences entre l'ancienne version amont, la nouvelle et la version Debian sont fusionnées.

Créer un instantané de la version Debian (l'étiqueter à l'aide d'un « tag ») est possible, ainsi que revenir à un état précédent, ou voir les modifications réalisées entre les fichiers. Lors d'une propagation (« commit »), le fichier peut être conservé ou des marques personnalisées (« propriétés ») peuvent être placées pour servir à des fins diverses.