Nous avons vu que les numéros de
révisions démarraient à 1.1 et, qu'ensuite, la commande ci
incrémentait uniquement le level number. Pour incrémenter le
release number il faut le faire explicitement avec l'option
-r de ci, par exemple :
ci -r2.1 foo.c
assigne le numéro 2.1 à la nouvelle révision. Un nouveau check-in donnera ensuite 2.2.
Un arbre de révision est constitué normalement d'une branche unique appelée tronc. On peut néanmoins créer des branches latérales. Par exemple, supposons l'arbre de révision suivant :
1.1 -> 1.2 -> 1.3 -> 1.4 -> 2.1 -> 2.2 -> 2.3 ...
Cet arbre a 7 révisions groupées en 2 releases. La release 1.4 est en activité sur un site client, tandis que la release 2 est en développement.
Imaginons maintenant que le client demande une correction dans la révision 1.4. Nous allons alors créer une branche à la révision 1.4, et insérer les corrections sur cette branche. La première branche démarrant à 1.4 est numérotée 1.4.1 et les révisions sur cette branche sont numérotées 1.4.1.1, 1.4.1.2, 1.4.1.3 ... Cette notation permet de créer d'autres branches à partir de 1.4. Les étapes nécessaires sont les suivantes :
co -r1.4 foo.c
editer foo.c pour apporter les corrections
ci -r1.4.1 foo.c
Nous obtenons alors l'arbre suivant :
1.1 -> 1.2 -> 1.3 -> 1.4 -> 2.1 -> 2.2 -> 2.3 ...
\
\
\> 1.4.1.1 -> ...
Il peut être nécessaire d'incorporer les différences entre 1.4 et
1.4.1.1 dans une révision de la release 2. Pour cela, il faut utiliser
la commande rcsmerge qui automatise le processus.
Une autre raison de créer une branche est liée au problème posé par un
programmeur ayant verrouillé une révision pour la modifier et qui n'a
pas encore effectué le dépôt de ses modifications. Si un autre
programmeur désire modifier cette révision, il ne peut pas le faire
tant que le verrou n'est pas supprimé. La solution est de créer une
branche, et ensuite, une fois que le premier programmeur a effectué
son check-in, utiliser la commande rcsmerge pour
incorporer les deux révisions.