SVN - rassembler plusieurs projets dans une seule version de référence

Question

Je suis vraiment nouveau à Subversion et les concepts de contrôle de version, et tandis que je peux gérer la vérification d'une poignée de fichiers dans un projet, j'ai besoin de conseils sur la façon d'échelle ceci pour mes besoins. Essentiellement, nous développons un environnement qui contient beaucoup de scripts et de configurations, répartis sur de nombreuses machines virtuelles et physiques. Construire des scripts, des fichiers de configuration, des binaires, des miroirs RPM, etc ... et bien que chacun dans leur propre monde soit OK, nous avons besoin d'un moyen de les agréger en une seule version. Alors que dans un projet de codage plus grand, je vois que cela serait probablement gérer avec des dossiers dans un seul projet SVN (si je comprends bien, donc probablement pas ...) ces thigns n'ont rien en commun, et beaucoup ne sont même pas le code , et serait juste au sein de SVN comme un lieu que j'imagine. En tant que tel, cela n'a aucun sens de "vérifier" la masse de données assemblée, mais de toute façon besoin de relier un numéro de version de niveau supérieur à peut-être 60 différents travaux. Comme ci-dessus, il s'agit de code, de fichiers de configuration, de rpm, etc.

Je suppose initialement que nous utiliserions SVN pour cela, mais c'est peut-être une fausse supposition dans un premier temps. Cependant, de ma vue générale des exigences je peux imaginer avoir les projets réels dans SVN et ensuite les projets wrapper qui sont mis à jour sur un cronjob (ou autre déclencheur) pour référencer les versions SVN les plus récentes de chaque projet répertorié dans un fichier de métadonnées dans le projet d'emballage. Si un projet de la liste a été modifié, ce projet d'encapsuleur est mis à jour avec un nouveau fichier de métadonnées en cours d'archivage. À leur tour, ces enveloppes sont enveloppées par d'autres enveloppes jusqu'à un seul projet maître. L'utilisation finale de cette version de projet maître est d'établir une base de projets sous-jacents, qui pourraient être utilisés avec la documentation et les systèmes de suivi des changements, avec un niveau d'automatisation également. Alors que je peux envisager ce que je viens de décrire, c'est seulement basé sur une très petite vue de SVN et probablement (espérons-le) manquant beaucoup de l'existence de SVN (ou git ....?). J'espère que cela a du sens, désolé si ce n'est pas le cas. Plus qu'heureux d'essayer de clarifier quoi que ce soit.

Merci

Chris

EDIT: Pour donner un exemple du genre de choses individuelles dont nous avons besoin pour couvrir:

• La version spécifique des dépôts CentOS rpm, tel que défini par la heure à laquelle il a été synchronisé à partir du Web
• Fichiers de configuration Nagios à installer dans un VM après l'installation des paquets Nagios
• Les scripts kickstart utilisés pour construire les serveurs virtuels
• Les scripts utilisés pour déclencher le déploiement des systèmes
• Les iptables ensembles de règles appliquées à chaque type de machine virtuelle

Je ne suis pas inquiet ici à propos de comment ces choses sont faites dans le moindre, plus comment nous présentons une vue d'une quelle version de chacune de ces choses est nécessaire au moment du déploiement.

[EDIT] OK, tout se résume à ne pas vraiment comprendre svn versioning. Comme le numéro de révision est vaste, tous les projets sont couverts implicitement ... aucun travail réel n'est requis pour réaliser ce que je voulais. Merci, et pas étonnant que je n'aie pas beaucoup de sens pour quelqu'un d'autre ..

Answer 1

Qu'est-ce que vous voulez est SVN Externals

Answer 2

Je ne suis pas sûr que je comprends la question, mais vous pouvez stocker beaucoup de choses différentes dans des répertoires différents dans SVN. Vous pouvez ensuite utiliser la fonctionnalité sparse directory pour récupérer uniquement certaines parties du référentiel. Par conséquent, vous pouvez stocker la configuration de chaque machine séparément si vous le souhaitez, et ne vérifier que le répertoire de cette machine sur une machine particulière.

Ce que vous ne pouvez pas faire dans SVN est d'avoir le même fichier présenté à 2 endroits différents. Vous ne pouvez donc pas stocker abc.config dans un répertoire de niveau supérieur, puis afficher ce fichier dans deux arborescences de répertoires différentes. Vous pouvez le faire en utilisant des externes cependant.