Empêcher les vérifications à SVN

Question

Mon équipe utilise SVN pour notre plate-forme logicielle, et nous créons périodiquement des balises pour aider à garder les versions des modules droites. La meilleure pratique, si je comprends bien, est de ne pas modifier une étiquette une fois qu'elle a été créée. Cependant, il semble que parfois la tentation est trop grande et une modification est apportée à l'un des tags.

Existe-t-il un moyen d'empêcher ce type de vérifications, ou au moins de leur faire une douleur complète afin que nous puissions les décourager automatiquement?

Merci, Joe

Answer 1

Créer un crochet pre-commit qui rejettera la commettras si la balise existe déjà. Plus de détails sur la mise en œuvre des crochets se trouvent ici (voir la section hooks du référentiel de mise en œuvre):

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html

Answer 2

Il me semble que vous essayez de trouver une solution technique à un problème non technique. Vous devez identifier pourquoi ces vérifications sont faites avant de déterminer comment les traiter. Si elles sont faites avec l'approbation de la direction de l'équipe, aucune quantité de processus ne les empêchera de se produire à l'avenir. Si d'un autre côté ces vérifications sont faites par des membres individuels de l'équipe qui pensaient qu'ils savaient mieux - eh bien, alors vous obtenez le leadership nécessaire pour résoudre le problème d'un développeur escroc.

Ce n'est qu'une fois que toute l'équipe aura déterminé ce qui est attendu une fois qu'un tag a été créé, que vous pourrez appliquer ces attentes avec une solution technique (si nécessaire). En ce qui concerne la façon d'empêcher les vérifications - il me semble que la solution la plus simple serait une fois que vous avez créé la balise pour définir la sécurité en lecture seule pour tout le monde à travers le path-based authorization. A noter cependant, que les auteurs du livre SVN également indiquer explicitement ce qui suit sur l'autorisation à base de chemin:

Notez, cependant, qu'il ya souvent invisible (et visible!) Coûts associés à cette fonction. Dans la catégorie visible, le serveur doit faire beaucoup plus de travail pour s'assurer que l'utilisateur a le droit de lire ou d'écrire chaque chemin spécifique; dans certaines situations , il y a une perte de performance très visible . Dans la catégorie invisible , considérez la culture que vous créez . La plupart du temps, alors que certains utilisateurs ne doivent pas commettraient modifications à certaines parties du référentiel , ce contrat social n'a pas besoin d'être technologiquement appliquées.