Est-ce qu'un système de contrôle de version possède une fonction de "modification persistante uniquement locale" ?

Question

Cette question m'est venue en jouant avec git, mais je vais poser le cas général...

Je viens de penser à une fonctionnalité qui pourrait être intéressante pour le contrôle de version, mais je ne sais pas si elle existe ou comment elle s'appelle. Je veux l'appeler changements locaux persistants.

Disons que j'ai un fichier de configuration dans svn, qui contient beaucoup de choses utiles non recréables (et qui doit donc être dans le contrôle de version), mais qui a une section que chacun doit éditer pour lui-même. Il peut s'agir d'une configuration de base de données, d'un nom d'utilisateur et d'un mot de passe, ou du chemin local d'un logiciel tiers. Vos options dans cette situation sont

1. Modifier les guerres dans le contrôle de version. Il suffit de continuer à modifier le fichier et d'espérer que tout le monde abandonne l'édition du fichier avant vous.

2. Modifiez-le, mais ne livrez jamais ces changements. Ils restent là et rendent votre commande "What's new/changed" sale, et vous devez vous rappeler de ne pas les livrer.

3. Le modèle. Retirez le fichier du contrôle de version et enregistrez une copie de celui-ci avec .template à la fin. Copiez localement le fichier et renommez-le, avec vos modifications.

4. Utilisez la nouvelle fonctionnalité (fictive ?) de changement local persistant. Effectuez votre modification puis lancez la commande record-changes-as-local-persistent, qui détermine un correctif, et après chaque mise à jour réapplique votre correctif.

Cette fonctionnalité existe-t-elle quelque part (cela ressemble à git stash, mais le but est légèrement différent) ? Si elle n'existe pas, y a-t-il une bonne raison de ne pas le faire ? (quelqu'un y a-t-il pensé et décidé que c'était une mauvaise idée ?)

Answer 1

J'ai toujours fait en sorte d'éviter cette situation.

J'essaie de rendre tous les environnements aussi semblables les uns aux autres que possible. Les seules choses qui diffèrent sont généralement les logins et parfois les URL des services d'infrastructure (BD, courtier en messages, services de données d'entreprise, etc.)

L'environnement de développement de tous les développeurs est configuré exactement de la même manière et la configuration des environnements de développement est vérifiée afin que les développeurs puissent simplement extraire le code du contrôle de version et le construire, sans autre manipulation.

Les mots de passe et la configuration des environnements de test et de CI sont enregistrés, de sorte que les serveurs de construction et de déploiement peuvent automatiquement mettre en service les systèmes dans les environnements de test.

Les mots de passe pour la production ne sont jamais enregistrés (c'est souvent une exigence légale là où je travaille) et les administrateurs maintiennent le fichier des mots de passe dans l'environnement de production.

Answer 2

Je fais la même chose sur monotone en utilisant le propagate commandement.

En bref, j'ai une branche 'développement' et une branche 'déployée'. Dans la branche déployée, la configuration a quelques paramètres différents (quelques répertoires et DEBUG=False). Lorsque je veux déployer, je fais un mtn propagate de la branche de développement à la branche déployée. ensuite, sur le serveur, je fais un pull and update, de sorte que l'espace de travail reçoit les dernières modifications de sa branche, qui incluent tous les nouveaux développements, mais respectent les différences de réglage.

Answer 3

Vous pouvez en quelque sorte faire cela avec SVN.

Si vous extrayez un fichier de la bibliothèque et que vous y apportez des modifications, et que vous effectuez ensuite une "mise à jour", vous obtenez la nouvelle copie du fichier de la bibliothèque avec vos modifications appliquées. J'utilise régulièrement cette méthode pour les fichiers de configuration.

Ce n'est pas tout à fait comme ce que vous décrivez car à chaque fois que vous faites un commit, vous devez exclure le fichier de configuration. Je suppose que si vous oubliez de le faire à un moment donné, vous mettrez à jour le référentiel avec vos modifications locales et causerez des problèmes à tout le monde.

Et lorsque vous devez modifier la partie "publique" du fichier de configuration, vous devez effectuer une vérification séparée afin de séparer les modifications "publiques" des modifications "locales".

J'approuverais également des schémas comme celui décrit par Chris Marisic. J'ai quelques applications Web pour lesquelles j'ai créé plusieurs fichiers de configuration, et le programme décide dynamiquement lequel utiliser en fonction de l'environnement.

Dans un cas, le fichier de configuration comprend des chemins vers des fichiers externes, et je travaillais à la fois avec un serveur Windows et un serveur Linux, de sorte que les noms de chemin sont différents. J'ai donc fini par créer une "configuration Linux" et une "configuration Windows", puis par choisir en fonction du système d'exploitation sous lequel je fonctionnais.

Dans l'autre cas, le programme au démarrage vérifie le nom du contexte de la servlet (il s'agit d'une application JSP/servlet), puis cherche un fichier nommé "WEB-INF/.properties". S'il ne le trouve pas, il charge un nom par défaut. Ensuite, j'exécute la version de développement sous un nom de contexte différent de celui de la version de production, et chaque version récupère automatiquement le bon fichier de configuration.

Answer 4

Mercurial peut ajouter un fichier local à .hgignore et ainsi être ignoré - ainsi il ne s'assied pas sur vos fichiers modifiés ou autre.