Soyez prudent. Vous devez également vous assurer que le commentaire par défaut ne devient pas une béquille. Par exemple, vous devez valider que le numéro de défaut est valide (actuellement ouvert, par exemple, et existe réellement). Sinon, les programmeurs utiliseront simplement le commentaire par défaut comme seul commentaire. À mon avis, il vaudrait mieux s'efforcer de valider le commentaire plutôt que de fournir une valeur par défaut. Dites aux développeurs que leurs modifications seront rejetées à moins que les commentaires répondent aux exigences - et documenter ce qui est attendu (et accepté).
Le questionneur défis « dit bien, mais ne répond pas à la question ».
Assez juste. Je n'utilise pas vraiment CVS, alors prenez ce qui suit avec une pincée de sel. En regardant le livre de Karl Fogel "Développement Open Source avec CVS" (Coriolis, 1999), je ne vois pas de bon moyen de le faire. Il existe des fichiers 'commitinfo', 'loginfo' et 'verifymsg' qui semblent tous spécifier des programmes validant les messages de journal, et l'éditeur est lancé lorsque l'utilisateur ne spécifie pas 'cvs ci -m"Why I committed this"
' (ou 'cvs ci -F why
' pour un message dans un fichier), mais personnellement je vérifie toujours avec des commentaires sur la ligne de commande et je détesterais avoir un éditeur lancé pour moi. Donc, à court d'écrire un wrapper pour la commande cvs
(ce qui serait modérément complexe), je ne vois pas de moyen dans le livre de faire ce que vous demandez.
Hmmm ... sauf si vous remplacez la définition de l'utilisateur de CVSEDITOR dans un wrapper de script shell pour cvs
avec un programme qui crée le message par défaut dans le fichier donné, puis lance ${VISUAL:-${EDITOR:-vim}}
à la place. Ick, et aussi beurk! Mais, fait avec soin, cela fonctionnerait. Probablement le plus difficile est de s'assurer que les programmeurs utilisent votre version de script de cvs
au lieu du binaire.
+1 - Réponse très responsable et réfléchie. D'accord avec votre solution 100%. –
J'ai mis à jour la question. Nous faisons déjà les vérifications suggérées. Je voudrais par défaut le commentaire par commodité et empêcher les développeurs d'une faute de frappe comme "Cahnge #: ..." –
Ceci est bien dit, et un excellent point, mais ne répond pas à la question posée. Des idées? –