Cette question s'est produite pour moi tout en jouant avec Git, mais je vais demander au cas général ...
Je viens de penser à une caractéristique qui pourrait être agréable pour le contrôle de la version, mais je ne sais pas si cela existe ou ce qu'on appelle. Je veux appeler cela des changements locaux persistants.
Dis que j'ai un fichier de configuration dans svn, qui possède de nombreux éléments utiles non reconstruisables (et doit donc être dans la version de la version), mais dispose d'une section que tout le monde doit éditer pour eux-mêmes. Peut-être une configuration de base de données ou un nom d'utilisateur et un mot de passe, ou le chemin local de certains logiciels tiers. Vos options dans cette situation sont
Modifier les guerres en version de version. Continuez simplement à changer le fichier et espérons que tout le monde abandonne l'édition du fichier avant de le faire.
Modifiez-le, mais ne commettez jamais ces changements. Ils sont juste assis là-bas rendant votre commande «Qu'est-ce qui est neuf / changé» l'air sale et que vous devez vous rappeler de ne pas l'engager.
gabarit. Supprimez le fichier de la version de la version et vérifiez une copie avec .template à la fin. Copiez localement le fichier et renommez-le, avec vos modifications.
Utilisez la nouvelle fonctionnalité de changement locale persistante (fictive?). Faites votre changement puis émettez la commande Record-Changements-AS-local-Persistant, qui figure sur un correctif, et après chaque mise à jour réapplique votre patch.
Cette fonctionnalité existe-t-elle n'importe où (on se sent comme une cachette git, mais le but est légèrement différent)? Si cela n'existe pas, y a-t-il une bonne raison pour laquelle non? (Quelqu'un a-t-il pensé à ce sujet et a décidé que c'était une mauvaise idée?)
9 Réponses :
Ceci est faisable si vous pouvez combiner plusieurs référentiels dans un arbre de travail. La solution la plus simple serait des liens symboliques.
Le problème (ce qui le rend dur) est que VCSS veut préserver la notion de jeux de changement. Donc, si vous valez un tel fichier avec des fichiers Versed réguliers - si les modifications appartiennent à la modification ou non? Avoir le même changements signifie que différentes choses sur différentes machines sont clairement déroutant.
Avec plusieurs référentiels, vous pouvez certainement avoir des engagements qui vont dans un référentiel ou l'autre. Combien de configuration locale que cela nécessite dépend du système VCS. Par exemple, pour svn: externes, vous devez utiliser le même fichier fichier sur chaque machine, mais ils pourraient indiquer différents ensembles de fichiers. Avec des liens symboliques, vous pouvez l'organiser sous n'importe quelle forme que vous s'il vous plaît (en supposant que le symbolique lui-même n'est pas versé).
J'ai toujours abordé cela en travaillant pour éviter la situation tout à fait.
J'essaie de faire tous les environnements aussi semblables que possible. Les seules choses qui diffèrent sont généralement des connexions et parfois des URL des services d'infrastructure (dB, courtier de 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 cochée dans les développeurs afin que les développeurs puissent simplement consulter le code à partir du contrôle de la version et de la construction, sans autre violation.
Les mots de passe et la configuration des environnements CI et des tests sont enregistrés. Les serveurs de construction et de déploiement peuvent donc élever automatiquement des systèmes dans des environnements de test.
Les mots de passe de production ne sont jamais enregistrés (c'est souvent une exigence légale dans laquelle je travaille) et les administrateurs gèrent le fichier de mot de passe dans l'environnement de production.
Je fais une chose similaire sur monotone , à l'aide de la commande 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 (certains répertoires et débogage = faux). Lorsque je veux déployer, je fais un propager .
MTN propagate du développement à la branche déployée. Ensuite, sur le serveur, je fais une traction et une mise à jour, l'espace de travail obtient donc les dernières modifications de sa branche, qui incluent tous les nouveaux développements, mais respectent les différences de fixation.
Vous pouvez ignorer tout fichier de configuration à partir du contrôle de la version. C'est le fichier .gitignore .
Par exemple, si vous souhaitez ignorer tout votre répertoire de journal , vous ajoutez une ligne à ce fichier avec: p> pour ignorer le fichier .ds_store, vous ajoutez une ligne avec: p> production:
database: project_database
username: database_user
password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %>
Ceci pourrait être un peu plus spécifique à Visual Studio, mais je suppose que la plupart des IDes auront une fonctionnalité similaire.
Dans toutes mes applications / configures Web contenant des paramètres qui changent pour différents environnements que je les divisons dans leurs propres fichiers. de sorte que ma configuration principale ressemble à ceci puis pour chaque fichier, il est similaire à après que je crée des dossiers Pour chaque environnement Dev / Staging / Prod, etc. et utilisez un fichier sous-configuration différent dans chaque dossier afin que tous les paramètres puissent être vérifiés dans TFS. J'ai mon configuration de projet de déploiement Web pour tirer dans les fichiers appropriés par configuration de version. Plus tard, lorsque je configure TFS pour gérer mes sorties, cela peut facilement être obtenu en suffisant en suffisant en suffissant de copier la configuration correcte. À ce stade, vous pouvez vérifier dans une base de référence pour le programme, puis lorsque les développeurs ont besoin de changer de choses. Pour eux-mêmes seulement qu'ils ne prévoient pas d'enregistrer, ils peuvent facilement simplement rendre le fichier non redonnés et le modifier.
DARCS le fournit. Vous pouvez enregistrer un correctif des modifications apportées aux paramètres de votre référentiel local et ne le poussez jamais à un autre référentiel. Malheureusement, le FAQ déclare Il n'est pas possible de signaler un patch comme local uniquement.
Une fois pourrait contourner cette limitation, cependant, en ayant un deuxième référentiel qui contient uniquement les correctifs propres à votre référentiel.
Vous pouvez trier un peu le faire avec SVN.
Si vous cochez un fichier de la bibliothèque et apportez-y les modifications, puis effectuez une "mise à jour", vous obtenez la nouvelle copie du fichier de la bibliothèque avec vos modifications appliquées. J'utilise cela régulièrement 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 changements locaux et que tout le monde est un chagrin.
Et lorsque vous devez modifier la partie "publique" du fichier de configuration, vous devez effectuer un chèque séparé de sorte que vous pouvez séparer les modifications "publiques" des modifications "locales".
J'approuverais aussi des schémas comme Chris Marisic décrit. J'ai quelques applications Web où j'ai créé plusieurs fichiers de configuration et que le programme décide de manière dynamique laquelle à utiliser en fonction de l'environnement.
Dans un cas, le fichier de configuration inclut des chemins vers des fichiers externes et je travaillais avec un serveur Windows et un serveur Linux afin que les noms de chemin sont différents. J'ai donc fini par créer une "configuration Linux" et une "configuration de Windows", puis cueillette en fonction du système d'exploitation que j'étais exécuté sous.
Dans l'autre cas, le programme au démarrage vérifie le nom du contexte de servlet (c'est une application JSP / servlet), puis recherche 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, puis la version de production, et chaque fichier de configuration correct est automatiquement.
Vous pouvez le faire en git avec une branche principale (ou "fournisseur") et une branche locale. Vos commits locaux vont sur la branche locale et vous la reconquassez sur le dessus du maître lorsque cela change. Si vous ne spécifiez pas une télécommande pour la succursale locale, vous ne pourrez pas la pousser accidentellement. Si vous vous engagez accidentellement quelque chose que vous voulez persister à la branche locale, choisissez un choix de cerisier à maîtriser et à pousser à partir de là.
+1. C'est la façon de le faire. Nettoyable et non intrusif, et vous n'avez pas besoin d'avoir des arbres de source sale avec des changements non engagés mentant.
Une fois que vous avez commencé à faire fusion de conflits, il est un peu équestre d'avoir à réparer les mêmes fonts à chaque fois que vous devez rebaser. Vous n'avez pas besoin de continuer à réparer les fonts si vous faites git fusion au lieu de git rebase , mais je ne sais pas si cela provoque d'autres problèmes ...
Mercurial peut ajouter un fichier local à .hgignore et donc être ignoré - alors il ne reste pas à gâcher vos fichiers modifiés ou autre.