Pourquoi ne puis-je pas modifier un message de validation SVN?

J'utilise SVN. Parfois, je manque quelque chose lorsque j'écris un message de validation. Mais une fois qu'il a été validé, il ne peut pas être annulé, et même je ne peux pas modifier le message. Pourquoi n'y ont-ils pas mis la fonction d'édition?

Selon la FAQ SVN, vous pouvez le faire si l'administrateur du référentiel l'a activé ou si vous disposez d'un accès administratif local au référentiel .

Cependant, cela est probablement une mauvaise idée. Vous changez en effet l'histoire. L'un des points du contrôle de version est de maintenir un historique et une piste d'audit pour le projet. Autoriser des modifications arbitraires de l'historique annule la piste d'audit. Au lieu de cela, je vous recommande d'effectuer des validations plus petites, d'écrire des messages de validation concis mais explicites et d'améliorer votre flux de travail personnel pour éviter ces erreurs.

Pour ce faire, vous devez essentiellement avoir des droits d'administrateur (directement ou indirectement) sur le référentiel. Vous pouvez soit configurer le référentiel pour permettre à tous les utilisateurs de le faire, soit modifier le message du journal directement sur le serveur.

Consultez la FAQ SVN ici.

Les messages de journal sont conservés dans le référentiel en tant que propriétés attachées à chaque révision. Par défaut, la propriété de message de journal (svn: log) ne peut pas être modifiée une fois qu'elle est validée. En effet, les modifications apportées aux propriétés de révision (dont svn: log en est un) entraînent la suppression définitive de la valeur précédente de la propriété et Subversion essaie de vous empêcher de le faire accidentellement. Cependant, il existe plusieurs façons d'obtenir que Subversion modifie une propriété de révision.

La première façon consiste pour l'administrateur du référentiel à activer les modifications des propriétés de révision. Cela se fait en créant un hook appelé "pre-revprop-change" (voir cette section dans le livre Subversion pour plus de détails sur la façon de procéder). Le hook "pre-revprop-change" a accès à l'ancien message de journal avant qu'il ne soit modifié, il peut donc le conserver d'une manière ou d'une autre (par exemple, en envoyant un e-mail). Une fois les modifications des propriétés de révision activées, vous pouvez modifier le message du journal d'une révision en passant le commutateur --revprop à svn propedit ou svn propset, comme l'un des deux:

$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 

où N est le numéro de révision dont vous souhaitez modifier le message de journal et URL est l'emplacement du référentiel. Si vous exécutez cette commande à partir d'une copie de travail, vous pouvez laisser l'URL.

La deuxième façon de modifier un message de journal consiste à utiliser svnadmin setlog. Cela doit être fait en se référant à l'emplacement du référentiel sur le système de fichiers. Vous ne pouvez pas modifier un référentiel distant à l'aide de cette commande.

$ svnadmin setlog REPOS_PATH -r N FILE

où REPOS_PATH est l'emplacement du référentiel, N est le numéro de révision dont vous souhaitez modifier le message de journal et FILE est un fichier contenant le nouveau message de journal. Si le hook "pre-revprop-change" n'est pas en place (ou si vous souhaitez contourner le script de hook pour une raison quelconque), vous pouvez également utiliser l'option --bypass-hooks. Cependant, si vous décidez d'utiliser cette option, soyez très prudent. Vous pouvez contourner des éléments tels que les notifications par e-mail de la modification ou les systèmes de sauvegarde qui gardent une trace des propriétés de révision.

Réponse de Kamil Kisiel en réponse à une question similaire sur Stack Overflow .

Parce qu'il s'agit d'un système de contrôle de version centralisé - Dès que vous validez une modification (et que votre message de validation est lié par convention au commit), tous ceux qui ont un accès en lecture au référentiel peuvent voir ces informations. C'est une mauvaise idée de changer une information après sa diffusion , car les gens se retrouvent avec une opinion différente de la «réalité».

Les systèmes de contrôle de version distribués comme Git atténuent ce problème en s'assurant que l'acte de rendre les informations disponibles pour les autres est atomique et sans aucune information supplémentaire comme les messages de validation. Mais le même principe s'applique ici: vous êtes découragé de changer localement des choses que vous avez déjà mises à la disposition des autres.