Le problème posé est le
suivant : au moins deux personnes veulent déposer des modifications
d'une même révision. Si nous supposons deux programmeurs apportant des
modifications à une même révision (par exemple la 2.5). Le programmeur
A fait un ci
sur sa révision avant le programmeur B. Le
programmeur B n'a pas vu les modifications de A, donc l'effet est que
les changements de A sont couverts par les modifications de B.
RCS prévient ce conflit par le verrouillage. Lorsque quelqu'un veut
éditer une révision pour la modifier, la révision doit être extraite
et verrouillée, en utilisant l'option -l
de co
. La
prochaine opération de check-in effacera le verrou. Au plus
un programmeur à la fois peut verrouiller une révision, et seulement
ce programmeur peut la déverrouiller.
Par exemple, supposons que le programmeur mad
a mis un verrou
par la commande co -l foo.c
. Maintenant, si le programmeur
gunsman
veut extraire la révision pour la modifier par la
même commande, il aura le message d'erreur suivant :
foo.c,v --> foo.c co: foo.c,v: Revision 1.2 is already locked by mad.
De plus, chaque fichier RCS possède également une liste d'accès, qui spécifie quels utilisateurs peuvent effectuer des opérations de mise à jour.