Comment commettre une révision de subversion avec chaque commit pour faire référence entre deux référentiels

Question

Considérer la propagation de logiciel dans deux dépôts séparés, Pub et Priv. Le référentiel Pub est public. Priv est fermé. Un serveur d'intégration continue construit à la fois Pub et Priv lorsque l'un ou l'autre des changements. Il crée ensuite des fichiers binaires téléchargeables à partir de Priv qui sont disponibles pour les utilisateurs de Pub. Ces binaires sont étiquetés en interne et sur le nom de fichier avec la révision de subversion. Question: Comment faire en sorte que les programmes construits à partir de Pub soient informés du bon numéro de révision Priv correspondant afin qu'ils puissent être téléchargés et exécutés automatiquement?

La solution actuelle consiste pour le serveur de génération à modifier les fichiers dans Pub pour définir le numéro de révision de Priv et valider ces modifications sur Pub. Cependant, cela pose 2 problèmes importants:

1. La construction prend beaucoup de temps donc si quelqu'un engage des modifications à Pub (ou Priv) lors de la construction, il crée des conflits. Cela peut être forcé, mais l'historique du journal semble étrange, comme si ces révisions l'avaient fait dans cette construction.

2. Le journal subversion contient de nombreuses entrées telles que "Création automatique mise à jour de la version". à chaque fois que la construction exécute une polution du journal de subversion autrement informatif.

Donc, nous pouvons le faire d'une manière qui ne nécessite pas de changer le référentiel.

Sincèrement, Wayne

Answer 1

je peux penser à plusieurs façons de le faire. Je suppose que pour une raison quelconque, il n'est pas possible de faire correspondre directement les numéros de révision, ce qui serait la solution la plus simple et la plus évidente. Une manière serait d'utiliser le message de validation de Pub pour inclure un pointeur vers la révision Priv correspondante, comme "Correspond à Priv r1234".

Un autre serait de stocker les correspondances à l'extérieur des dépôts, dans une base de données simple ou même un fichier texte, qui est mis à jour chaque fois qu'une validation de Priv est envoyée à Pub. Encore une autre façon serait de ne pas faire de commit séparé, comme vous le faites actuellement, pour enregistrer la révision Priv, mais pour ajouter cette modification au commit qui est censé être enregistré.

Answer 2

Vous pouvez utiliser un revision property (voir la section intitulée «Propriétés non versionnées) pour stocker la révision appropriée de Priv par rapport à la révision appropriée de Pub. La bonne chose à propos des propriétés de révision est qu'elles n'ont pas besoin d'être validées.

Les propriétés de révision, en langage Subversion, sont attachées à une révision particulière plutôt qu'à un dossier versionné Ces propriétés, contrairement aux propriétés attachées aux fichiers ou aux dossiers, ne sont pas versionnées. Dans TortoiseSVN, ils sont ajoutés via le journal de l'historique (faites un clic droit sur une révision puis sélectionnez "Afficher les propriétés de la révision") plutôt que les propriétés d'un fichier ou dossier et sont appliqués immédiatement sans faire de validation. Par exemple, pour associer r1234 de Priv à r6789 de Pub, vous pouvez le faire à partir d'une extraction de Pub.

svn propset --revprop -r6789 "priv:version" "1234" 

Maintenant, quand r6789 Pub est construit vous pouvez le faire

svn propget --revprop -r6789 "priv:version" 

pour récupérer le numéro de révision appropriée de Priv. Afin de faire face à d'autres commits qui se produisent après la dernière construction Priv, votre script devrait "marcher" dans l'historique demandant à chaque révision de "priv: version" jusqu'à ce que vous obteniez une valeur. Ou vous pourriez avoir un crochet post-commit qui copie la propriété à chaque révision au moment où elle se produit.

Un gotcha cependant. Vous devez avoir un hook pre-revprop-change qui vous permettra de travailler avec les propriétés de révision. Le plus simple est de toujours retourner 0 pour que tout revprop soit autorisé. Sous Windows, je crée simplement un fichier "pre-revprop-change.bat" vide dans le répertoire hooks. Si vous jetez un coup d'oeil à l'exemple de script hook fourni lors de la création d'une propriété, il est en fait assez bien documenté.

Answer 3

Désolé, stackoverflow ne permet pas de répondre ou de modifier à mon message moi-même ou vos réponses depuis que je n'étais pas inscrit lorsque j'ai posé cette question. Donc, voici les réponses ...

Simon: Merci. Pourquoi proposez-vous que les propriétés de révision ne nécessitent pas de validation? Le script de construction nant utilise actuellement les propriétés de révision pour garder une trace des versions de branches pour la fusion et la réintégration (la capacité de fusion intégrée de svn est trop facilement confondue). Mais ces propriétés de révision nécessitent de s'engager à se rendre dans le référentiel central et votre lien fait référence au même type de propriétés de révision utilisées pour cela. Parlez-vous d'un autre type de propriétés de révision? Compétence critique: Oui, les messages pour valider «Autobuild mis à jour vers la version 0.5.6.1049» sont personnalisables. Ce commit se passe réellement dans le script de construction nant qui est exécuté par CI en utilisant Hudson. Et, rappelez-vous, nous aimerions éliminer ce commit car chaque commit de Pub est suivi par un (ou plusieurs) de ces messages automatisés qui polluent les logs.

Marque: re: Commit pointeur sur Priv. Les utilisateurs qui s'engagent à pub n'ont aucun accès à Priv, ils ne savent donc pas quelle révision - sinon une bonne idée. D'un autre côté, la compilation automatisée fait cela maintenant quand elle construit pub et priv mais cela pollue le fichier journal avec des tonnes de commits automatisés simplement pour lier les versions sans autre changement substantiel à Priv.

Mark: Nous avons envisagé de stocker les correspondances en dehors des dépôts mais cela conduit à un autre problème que nous ne pouvons pas résoudre. Résolvez cela et vous gagnez la réponse. Le problème est que le dépôt pub contient un logiciel qui dépend des binaires construits à partir de Priv avec la version exactement correspondante. Il inclut donc une fonctionnalité de "mise à jour automatique" qui se connecte au serveur qui contient Priv et demande l'affichage de binaires et les télécharge. La clé est que le paramètre principal pour lancer ce téléchargement est la version.

Mark: Donc la question est de savoir comment le Pub peut savoir quelle version télécharger? À l'heure actuelle, cela est résolu par la situation dans la question initiale. Le script auto build nant valide une modification du code source dans Pub pour inclure le numéro de version de Priv, mais c'est ce qui pollue les journaux Pub avec "Auto build mis à jour la version ..". L'outil de mise à jour automatique utilise cette version si priv pour demander au serveur Web les binaires Priv. Et tout fonctionne. Mark: Les problèmes secondaires semblent, dans un premier temps, être résolus en changeant la relation pour avoir la mise à jour automatique du logiciel Pub en utilisant la version - la version de Pub - et le serveur web l'utilise en utilisant un fichier séparé pour obtenir la version la plus récente des fichiers binaires Priv. Cependant, il semble qu'il n'y ait aucun moyen pratique pour que le logiciel Pub connaisse la version de chaque commit.

Marque: Si vous mettez $ Rev $ keyword dans le code de mise à jour automatique, il ne sera mis à jour que ce même fichier a été modifié. Cela semble être un défi «ancien» dans le travail avec Subversion. Il semble qu'un hook de pré-commit pourrait mettre à jour le code source avec une version mais il semble que seulement fonctionne quelqu'un qui valide le fichier source auto udpate en question. Mark: Votre dernière idée était un peu confuse, mais il semble que ce soit le même que mentionné précédemment pour inclure les informations de version avec le commit à Pub plutôt que d'avoir un commit automatisé supplémentaire. J'aime ça mais je n'arrive pas à comprendre (après googler et lire des forums et des posts pendant plus d'une journée). Il semble être un défi commun de savoir comment valider la version étendue du projet avec n'importe quel commit ordinaire à Subversion, car il ne gère que les versions des fichiers individuellement. Même si vous utilisez svnversion dans un hook de pré-commit, il ne met à jour que les fichiers modifiés, n'est-ce pas? Alors, comment le code source de construction automatique sait quelle version quand il s'exécute?

Tout le monde: Merci à vous tous pour vos questions et réponses. Cela aide à affiner la compréhension de la question afin que nous puissions arriver à une solution! ALORS. C'est cool!