2009-05-21 11 views
51

Est-il possible d'ignorer les modifications apportées à un fichier dans subversion localement sur un seul client, sans propager l'ignorer dans l'ensemble du référentiel?Subversion: ignorer les modifications apportées à un fichier localement sur un seul client

Le problème particulier auquel je suis confronté est que j'ai vérifié un projet et modifié un tas de fichiers, y compris le Makefile, qui fait déjà partie du référentiel. Maintenant, l'environnement sur lequel je travaille est différent du reste du groupe, et je veux que les modifications apportées aux Makefiles restent locales sur ma machine et ne soient pas validées.

Cependant, je ne veux pas mettre svn: ignore parce que je crois que je commettrais l'ignorer dans le dépôt, alors qu'il est important de garder le fichier make là.

+4

Fondamentalement, je pense que vous essayez de résoudre le mauvais problème. Pourquoi ne pas modifier vos Makefiles pour qu'ils fonctionnent correctement dans les deux environnements? –

+22

Nicholas, même si fuad n'utilise pas la meilleure approche à son problème, je suis à peu près sûr qu'il existe des raisons légitimes de créer des ignorés qui ne s'appliquent qu'à votre copie de travail. – allyourcode

+7

Je suis d'accord avec allyourcode. Un développeur (utilisateur de svn) pourrait ne pas avoir le privilège ou le désir de changer les principes fondamentaux. Je voudrais aussi une solution à ce problème. Nous avons des fichiers de propriétés d'environnement archivés dans notre repo. Quand je les change localement, je dois les décocher manuellement quand je fais des checkins. Ce n'est qu'une question de temps avant que j'oublie de les décocher.Je suis d'accord que ces fichiers ne devraient pas être dans notre repo, mais je n'ai pas le pouvoir de prendre cette décision, donc j'ai vraiment besoin d'une solution de contournement. – andersonbd1

Répondre

-3

Utilisez svn export pour exporter le fichier afin qu'il ne soit pas sous contrôle de version.

http://svnbook.red-bean.com/en/1.0/re10.html

edit: Mais je crois que cela doit être fait sur un, alors vous auriez à réorganiser un peu vos fichiers de chaque répertoire.

Je ne peux pas tester cela pour le moment, mais un contrôle clairsemé vous aiderait-il ici?

http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

+0

Ne fonctionne pas, fait toujours partie du référentiel et apparaît comme modifié – fuad

+1

Je ne suis pas sûr qu'il est possible d'avoir des fichiers exportés dans un répertoire versionné. –

+0

Je ne sais pas pourquoi cela a été rejeté si lourdement. Cela fonctionne dans un certain nombre de situations où d'autres solutions ne le font pas. Plus particulièrement, cela fonctionne pour moi parce que j'avais deux exigences supplémentaires. 1) Non TortoiseSVN (je suis sous OS X) 2) Je ne veux pas ajuster mes habitudes pour tenir compte des listes de changements. Edit: Testé et fonctionnant à l'intérieur d'un répertoire versionné btw. Vous pouvez supprimer le répertoire donné (depuis l'intérieur du répertoire) avec "svn update --set-depth = empty" et ensuite vous devez le vérifier avec "svn export --force svnrepopath/directory." – radicaledward101

1

La plus proche solution sûre que je peux penser est d'utiliser une branche personnelle.

+1

Comment cela aide-t-il? Quand vous voulez revenir dans le coffre, vous aurez un autre problème (pire?): Ne pas fusionner les fichiers que vous voulez ignorer. – allyourcode

+1

Vous pouvez commettre votre changement personnel dans votre branche personnelle avec un message disant «ne pas fusionner» et faire attention à ce message lors de la fusion, il sera bientôt enterré sous des changements plus récents de toute façon; vous pouvez même marquer cette révision comme déjà fusionnée, ce qui devrait empêcher une fusion accidentelle. BTW Je ne connaissais pas les changelists et ils sont définitivement meilleurs qu'une branche dans ce but. – Gleb

10

si vous utilisez 1.5.x Subversion ou plus vous pouvez utiliser changelists:

svn cl COMMIT /path/to/project/* 

svn cl NOT_COMMIT /path/to/project/Makefile 

Note: avec la deuxième commande Makefile sera retirée de la première changelist. Vous pouvez ignorer l'avertissement.

Ne pas valider la deuxième liste de modifications.

do engage via:

svn ci --cl COMMIT -m"<LOG MESSAGE HERE>" 

Important: Si vous vous engagez sans -Cl option, toutes vos modifications seront engagés

+1

svn cl peut ne pas être une bonne option, car il ne supporte pas l'ajout de répertoires aux listes de modifications. C'est un problème s'il y a des répertoires que vous avez ajoutés dans votre commit. – allyourcode

+2

les changelists semblent utiles, mais je ne pense pas qu'ils s'appliquent vraiment ici. C'est un cas d'utilisation différent. Ils pourraient fonctionner si les commandes par défaut ignoraient les fichiers qui étaient dans une liste de modifications - ce serait très utile. Mais à moins que je me trompe, ce n'est pas comme ça que ça fonctionne. Si vous ne spécifiez pas de liste de modifications sur une commande, alors il se comporte comme si les listes de modifications n'existaient pas, correct? Donc même si les changelists supportaient les répertoires, ce ne serait pas une solution idéale. Vous devez déplacer manuellement les fichiers que vous voulez vraiment intégrer dans une liste de modifications. Je préfère marquer manuellement les fichiers que je ne veux pas vérifier. – andersonbd1

38

Comme de nombreux aspects de svn, tortue fait vraiment facile. En fait, je crois que Tortoise ajoute des fonctionnalités en utilisant systématiquement les fonctionnalités svn existantes. Je réalise que cette réponse ne concerne que les fenêtres, mais peut-être que certaines personnes sont comme moi et utilisent encore Windows. Dans la fenêtre "Vérifier les modifications", faites un clic droit sur vos fichiers et sélectionnez "Déplacer vers la liste de modifications" -> "Ignorer la validation". Maintenant, lorsque vous utilisez l'option tortue, les modifications sont segmentées dans les différentes listes de modifications, ce qui vous permet au moins de dire visuellement ce que vous voulez valider et ce que vous ne voulez pas valider.

+3

Nice! mais le fichier (et donc le dossier) apparaît toujours comme modifié. – Loda

+0

Oui, j'ai le même problème. Tout ce qu'il fait est de prévenir contre la mise à jour accidentelle/commital. – ArtB

+2

Comme indiqué précédemment, tout est parfait sauf qu'il montre que le fichier a été modifié. C'est mieux que d'avoir à décocher tous ces fichiers chaque fois que je m'engage, cependant. –

Questions connexes