Tu pourrais t'en sortir en créant ou en recherchant un hook sur le commit mais l'utilsateur ne sera prévenu qu'au moment du commit qu'il n'avait pas le droit de supprimer un fichier
Si tu veux un système à la ClearCase qui offre des hooks sur le client et qui permettrait de prévenir l'utilsateur dès qu'il lance la commande "svn del" c.a.d. avant le commit il faudrait locker tous les fichiers par défaut créer un hook pre-unlock et invoquer la commande snv unlock --force avant tout modification de fichier.
Tu aurais quelques chose d'équivalent à Clearcase. Sous Cleracase tous les fichiers sont en lecture seule. Avec la commande cleratool checkout -unreserved tu extrait un fichier pour modification et cette opération permet de déclencher un hook (trigger préop en jargon CC) sur cette opération. La différence serait que ton hoook se declencherait sur le serveur et pas en local.
Quoiqu'il en soit ca reste une solution très lourde et je me pose la question sur l'intêret d'un telle demande.
Il ne faut pas oublier que SVN à la différence de CVS supporte le versionnage des répertoires et que chaque commit crée une nouvelle révision complète de ton projet. Si un utilisateur supprime par erreur, un fichier tu as donc tjs moyen de le restaurer.
En outre il faut faire un minimum confiance à tes utilisateurs. En général choisir de supprimer avec une commande explicite comme "svn del" signifie que l'on sait ce que l'on veut faire. Bien que cela t'apportes une impression de sécurité, ca risque d'^tre contre-productif. Les developpeurs qui vont passer leur temps à demander des suppressions de répertoires et le compte privilégié va perdre son temps à traiter ces demandes.
# Hook
Posté par Bozo_le_clown . En réponse au message Limiter la suppression de fichier sous subversion. Évalué à 2.
Si tu veux un système à la ClearCase qui offre des hooks sur le client et qui permettrait de prévenir l'utilsateur dès qu'il lance la commande "svn del" c.a.d. avant le commit il faudrait locker tous les fichiers par défaut créer un hook pre-unlock et invoquer la commande snv unlock --force avant tout modification de fichier.
Tu aurais quelques chose d'équivalent à Clearcase. Sous Cleracase tous les fichiers sont en lecture seule. Avec la commande cleratool checkout -unreserved tu extrait un fichier pour modification et cette opération permet de déclencher un hook (trigger préop en jargon CC) sur cette opération. La différence serait que ton hoook se declencherait sur le serveur et pas en local.
Quoiqu'il en soit ca reste une solution très lourde et je me pose la question sur l'intêret d'un telle demande.
Il ne faut pas oublier que SVN à la différence de CVS supporte le versionnage des répertoires et que chaque commit crée une nouvelle révision complète de ton projet. Si un utilisateur supprime par erreur, un fichier tu as donc tjs moyen de le restaurer.
En outre il faut faire un minimum confiance à tes utilisateurs. En général choisir de supprimer avec une commande explicite comme "svn del" signifie que l'on sait ce que l'on veut faire. Bien que cela t'apportes une impression de sécurité, ca risque d'^tre contre-productif. Les developpeurs qui vont passer leur temps à demander des suppressions de répertoires et le compte privilégié va perdre son temps à traiter ces demandes.