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

Vous pouvez faire cela dans git avec une branche master (ou "vendor") et une branche locale. Vos commits locaux vont sur la branche locale, et vous la rebasez sur master quand elle change. Si vous ne spécifiez pas de remote pour la branche locale, vous ne pourrez pas la pousser accidentellement ; si vous commitez accidentellement quelque chose que vous voulez voir persister dans la branche locale, il suffit de faire un cherry-pick sur master et de pousser à partir de là.

Answer 2

Vous pouvez ignorer tout fichier de configuration du contrôle de version. C'est le .gitignore fichier.

Par exemple, si vous voulez ignorer tout votre répertoire de logs, vous ajoutez une ligne à ce fichier avec :

log/*

Pour ignorer le fichier .DS_Store, vous ajoutez une ligne avec :

.DS_Store

Vous pouvez alors mettre à jour le fichier localement, vous ne le verrez jamais dans les fichiers modifiés mais non engagés. Et si vous faites un git add . il ne sera pas ajouté au commit.

Si vous avez besoin de mettre votre fichier de configuration dans git mais de ne garder qu'un mot de passe ou une var quelque part, ce que je fais c'est appeler un fichier distant à l'intérieur de ce fichier de configuration. Et ce fichier contient mon mot de passe.

Sur un projet rails par exemple, la configuration de ma base de données ressemble à cela :

production:
 database: project_database
 username: database_user
 password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %>

Le fichier "path/to/my/password/file" n'est pas dans le contrôle de version.
Mon fichier de configuration est donc versionné. Mais le mot de passe dépend de la machine sur laquelle on se trouve.

Il présente également l'avantage de ne pas permettre à n'importe qui de lire les mots de passe dans votre contrôle de version.

Answer 3

C'est peut-être un peu plus spécifique à Visual Studio, mais je suppose que la plupart des IDE ont une fonction similaire.

Dans toutes mes configurations d'applications/de sites web dont les paramètres changent en fonction de l'environnement, je les répartis dans leurs propres fichiers de sorte que ma configuration principale ressemble à ceci

  <dataConfiguration configSource="Config\Development\dataConfiguration.config" />
  <connectionStrings configSource="Config\Development\connectionStrings.config" />
  <appSettings configSource="Config\Development\appSettings.config"/>

Ensuite, pour chaque fichier, c'est similaire à

<?xml version="1.0" encoding="utf-8" ?>
<dataConfiguration defaultDatabase="defaultDatabase"/>

Ensuite, je crée des dossiers pour chaque environnement Dev/Staging/Prod etc. et j'utilise un fichier de sous-configuration différent dans chaque dossier afin que tous les paramètres puissent être vérifiés dans TFS. J'ai configuré mon projet de déploiement web afin de récupérer les fichiers appropriés pour la configuration de la version. Plus tard, lorsque je configurerai TFS pour gérer mes versions, il suffira de lui demander de copier la bonne configuration.

À ce stade, vous pouvez enregistrer une base de référence pour le programme et ensuite, lorsque les développeurs ont besoin de modifier des choses pour eux-mêmes, mais qu'ils ne prévoient pas d'enregistrer, ils peuvent facilement rendre le fichier non accessible en lecture seule et le modifier.

Answer 4

Darcs fournit ceci. Vous pouvez enregistrer un patch des modifications apportées aux paramètres dans votre référentiel local et ne jamais le pousser vers un autre référentiel. Malheureusement, le Les états de la FAQ il n'est pas possible de marquer un patch comme local uniquement.

Vous pouvez cependant contourner cette limitation en ayant un second dépôt qui ne contient que les correctifs uniques pour votre dépôt.

Answer 5

C'est faisable si vous pouvez combiner plusieurs dépôts en un seul arbre de travail. La solution la plus simple serait les liens symboliques.

Le problème (qui rend les choses difficiles) est que les VCS veulent préserver la notion d'ensembles de modifications. Ainsi, si vous livrez un tel fichier avec des fichiers versionnés normaux, les modifications doivent-elles appartenir à l'ensemble de modifications ou non ? Avoir le même jeu de modifications signifiant différentes choses sur différentes machines est clairement déroutant.

Avec plusieurs dépôts, vous pouvez certainement avoir des commits qui vont dans un dépôt ou l'autre. La quantité de configuration locale nécessaire dépend du système VCS. Par exemple, pour svn:externals, vous aurez besoin d'utiliser le même système file: sur chaque machine, mais ils peuvent pointer vers différents ensembles de fichiers. Avec les liens symboliques, vous pouvez les organiser sous la forme que vous voulez (en supposant que le lien symbolique lui-même n'est pas versionné).