Subversion : empêcher les modifications locales d'un fichier d'être validées ?

Question

J'ai une copie de travail Subversion dans laquelle j'ai apporté quelques modifications locales à un fichier. Ces modifications ne concernent que moi, je ne veux pas les livrer. (La version dans le dépôt contient des valeurs par défaut qui conviennent aux autres utilisateurs, mais pas à moi, c'est pourquoi je veux les remplacer localement).

Notez que, bien que je ne veuille pas valider mes modifications, je faire Je souhaite recevoir toutes les mises à jour effectuées dans le référentiel lorsque je le fais. svn update . De plus, c'est seulement dans ma copie de travail que je ne veux pas valider les modifications de ce fichier, les autres utilisateurs ne devraient pas être affectés. Les autres utilisateurs ne devraient pas être affectés. svn:ignore ou engager des crochets qui ne correspondent pas à mon objectif.

Actuellement, c'est tout simplement le cas :

svn commit file1 file2...

où je spécifie explicitement les fichiers qui ont été modifiés à l'exclusion le fichier particulier que je ne veux pas valider.

Cependant, lorsque je travaille, j'ai l'habitude d'écrire tout simplement :

svn commit -m "Log of what I just did"

et je crains de commettre par inadvertance le fichier "interdit" en utilisant la commande ci-dessus à un moment où je ne suis pas attentif.

En bref, ce que je recherche est simplement un moyen de "marquer" un fichier dans une copie de travail qui empêche Subversion de livrer les changements dans ce fichier (cela n'a pas besoin d'être une exclusion automatique, même si j'obtiens juste une erreur lorsque j'essaie de livrer tous les fichiers, c'est bien). C'est un peu comme marquer les fichiers en état de "conflit"...

Une telle chose existe-t-elle ?

Mise à jour : akent, merci de l'avoir signalé question très similaire .

Answer 1

Il y a eu quelques réponses qui peuvent fonctionner :

1. Créer un crochet de pré-commission script qui rejette la validation lorsqu'une propriété spécifique est ajoutée. Vous pouvez ensuite ajouter cette propriété aux fichiers de la copie de travail pour empêcher les livraisons.
2. TortoiseSVN exclura les fichiers de la liste de modifications spéciale "ignore-on-commit". Cependant, ceci n'est pas honoré par le client en ligne de commande de SVN.

CoverosGene a suggéré que les commandes par défaut telles que svn commit opèrent sur une liste de modifications par défaut, de sorte que vous pouvez exclure un fichier si vous l'assignez à une autre liste de modifications, mais je n'ai trouvé aucune référence à cela dans la documentation, et dans mes tests cela ne fonctionne pas .

Comme il n'y a pas de bonne solution pour le client en ligne de commande SVN, j'ai ouvert une demande d'amélioration. aquí . La requête suggère que le client en ligne de commande pourrait également respecter la liste de modifications "ignore-on-commit".

Mise à jour : Ceci est maintenant numéro 2858 et il y a un aperçu des caractéristiques pour le traiter avec un svn:hold propriété.

Answer 2

Créer un liste des modifications avec ce fichier, et ne pas prêter attention à la liste des modifications. Le fichier restera là à attendre d'être livré, mais vos livraisons régulières, qui travaillent sur la liste de modifications par défaut, ne le prendront jamais.

svn changelist mylocal file1

créera une liste de modifications appelée mylocal et assigner le fichier file1 à elle.

Answer 3

Je comprends le problème que vous rencontrez ; ce fichier "interdit" contient probablement des paramètres de configuration et autres qui ne sont pertinents que pour votre environnement de construction local. Je n'ai pas trouvé de moyen direct de dire à SVN d'ignorer les changements dans un fichier versionné, mais voici une solution que j'ai utilisée dans le passé.

En supposant que votre fichier s'appelle, disons, "build.conf". Nommez le fichier versionné SVN quelque chose comme build.conf.example. Ensuite, dans votre Makefile ou build script ou autre, vous pouvez automatiquement copier le fichier build.conf.example dans le répertoire réel build.conf, qui reste non versionné. Ensuite, vous ignorez svn build.conf et chaque développeur peut alors y apporter les modifications locales dont il a besoin.

Mais "il doit y avoir un meilleur moyen"...

Edita: Question presque identique ici : SVN : Existe-t-il un moyen de marquer un fichier comme "do not commit" ?

Answer 4

En fait, un script script de pré-commission ferait l'affaire.

Écrire un script script qui exécute 'svnlook diff' et rejette le commit si une propriété nommée 'nocommit' est définie dans le jeu de modifications.

Ensuite, dans votre copie de travail, vous pouvez simplement définir une propriété "nocommit" sur tout fichier qui ne devrait pas être livré. Toute livraison ultérieure échouera si un fichier possède la propriété "nocommit". Si, par la suite, vous avez besoin d'enregistrer les modifications apportées au fichier, il vous suffit de supprimer la propriété "nocommit" de votre copie de travail.

Answer 5

D'après mon expérience : ne mettez pas ce fichier sous contrôle de version et utilisez svn:ignore sur lui.

C'est un peu difficile au début, car on ne peut pas ignorer un fichier qui est déjà sous contrôle de version, et on ne peut pas retirer un fichier du contrôle de version sans le retirer du disque dur (et de toutes les copies de travail lors de la prochaine mise à jour...). Mais lorsque vous parvenez enfin à configurer le repo correctement, cela fonctionne comme un charme. N'oubliez pas d'ajouter un modèle générique à la place de votre fichier de configuration original (afin que tout le monde soit au courant des nouvelles variables de configuration, et ainsi de suite).

Pour le nouveau repo :

mkdir config
svn add config
svn propset svn:ignore '*.conf' config 

Pour un repo existant : assurez-vous d'avoir une sauvegarde de votre configuration dans chaque copie de travail, puis supprimez (svn del) la configuration du repo, faites un commit (attention : le fichier sera supprimé dans chaque copie de travail lors de la prochaine mise à jour ! vous devez avoir une sauvegarde), puis restaurez le fichier et définissez la propriété ignore.

Une autre solution consiste à utiliser un cadenas. Il garantit que personne ne commettra le fichier, mais il en résultera une erreur à chaque livraison, ce qui n'est pas très agréable.

Et le troisième moyen - les changesets, une nouvelle fonctionnalité dans les clients SVN 1.5. C'est intéressant, mais cela ne concerne qu'une copie de travail, pas un dépôt dans son ensemble. Et il faut les configurer manuellement, ajouter chaque nouveau fichier - c'est difficile à maintenir.