2010-05-21 9 views
5

J'utilise subversion comme RCS. Toujours quand une nouvelle version de mon projet est finie je crée une étiquette (copie du tronc). Est-ce que quelqu'un sait comment je peux protéger ce répertoire étiqueté d'être accidentellement modifié? Pour l'instant comme une solution de contournement je verrouille tous les fichiers. Mais ce seuil signifie que l'utilisateur avec le verrou peut éditer les fichiers.Subversion: protection en écriture pour les répertoires marqués

Y a-t-il une meilleure solution?

Répondre

5

Vous pouvez utiliser un hook de pré-validation pour empêcher les utilisateurs d'écrire dans un répertoire tags après sa création.

Voir cette question relative SO exemples:
SVN pre-commit hook for avoiding changes to tags subdirectories

+0

Les hooks de pré-validation sont des scripts qui peuvent faire des choses plus complexes, comme ne permettre que des changements dans les répertoires de balises par certains utilisateurs. –

+0

Si un hook de pré-commit est le moyen officiel, je vais définir l'attribut SVN "svn: needs-lock" sur tous les fichiers à la place. – Alexander

+1

Ne pas définir la propriété sur tous les fichiers ... c'est contre l'idée de SVN. La réponse donnée à l'autorisation basée sur le chemin est la bonne. – khmarbaise

2

Vous pouvez donner lecture seule autorisation sur les répertoires d'étiquettes en utilisant path-based authorization.

+0

Le problème avec cette solution est que vous ne pouvez pas créer de nouveaux 'tags'. Si certains utilisateurs ont l'autorisation d'écriture, il est toujours possible de modifier par erreur les fichiers d'une balise. –

+0

Vous pouvez définir en lecture seule les balises après les avoir créées, laissant le sous-répertoire/tags accessible en écriture: es:/myproject/tags est accessible en écriture, alors que/myproject/tags/my-first-tag est défini sur readonly après la création du tag. –

0

Si vous définissez l'attribut svn:needs-lock pour tous les fichiers de la balise, tous les fichiers seront extraits en lecture seule à moins que l'utilisateur n'acquière explicitement un verrou. Cela (dans la plupart des cas) empêchera les fichiers d'être changés. Cela n'empêche personne de changer le drapeau en lecture seule ou d'acquérir un verrou, mais cela réduit les risques de modification accidentelle. Subversion lui-même ne peut pas appliquer l'attribut svn:needs-lock à un dossier, mais dans le client TortoiseSVN (Windows) par exemple si vous tentez de le faire, il applique la propriété à tous les fichiers du dossier et des sous-dossiers à la place. Il ne vous laissera pas faire cela à partir du repo-navigateur TortioseSVN, vous devez donc extraire une copie de travail de la balise, modifier les propriétés, puis vérifier les changements de propriétés. Les autres clients peuvent varier; Si vous utilisez le client de ligne de commande subversion natif, un script shell approprié ou similaire peut être nécessaire pour parcourir les fichiers et les sous-dossiers afin d'appliquer l'attribut en masse. TortoiseSVN vous avertit au moins si vous tentez de changer quoi que ce soit dans un dossier Tags - mais ce n'est qu'une convention, pas une application.

La solution svn:needs-lock est quelque peu faible et facilement contournée et n'empêche pas que de nouveaux fichiers soient ajoutés à un dossier d'étiquettes; une alternative plus forte consiste à créer un utilisateur fictif et à acquérir un verrou pour l'ensemble de la balise dans ce nom d'utilisateur. Cela empêchera les utilisateurs "réels" d'être en mesure de s'enregistrer, et les extractions de copie de travail auront leur attribut en lecture seule comme avec svn:needs-lock - la différence est qu'ils ne seront pas en mesure d'acquérir un verrou, et de changer le l'attribut de lecture seule de copie de travail n'autorisera pas l'archivage non plus.

+0

Je sais que la question est ancienne, mais je cherchais une solution à exactement cela et j'ai trouvé cette question. Cette réponse décrit ce que j'ai l'intention de faire actuellement, car il semble n'y avoir aucun soutien direct à cela. – Clifford