Comment synchroniser deux référentiels Subversion?
Mon entreprise possède une filiale avec une connexion Internet lente. Nos développeurs souffrent d'interagir avec notre serveur central Subversion . Est-il possible de configurer un esclave/miroir pour eux? Ils interagiraient localement avec le serveur et toutes les validations seraient automatiquement synchronisées avec le serveur maître.
Cela devrait fonctionner de la manière la plus transparente possible pour les développeurs. L'utilisabilité est un must.
S'il vous plaît, aucune suggestion pour changer notre système de contrôle de version.
Subversion 1.5 a introduit la prise en charge du proxy lorsque vous utilisez http pour héberger votre référentiel. Les développeurs peuvent extraire leurs copies de travail de l'esclave. Ensuite, toutes les opérations en lecture seule (diff, journal, mise à jour, etc.) utiliseront l'esclave. Lors de la validation, l'esclave transmet de manière transparente toutes les opérations d'écriture au maître.
C'est possible mais pas nécessairement simple: le problème que vous essayez de résoudre est dangereusement proche de la mise en place d'un environnement de développement distribué qui n'est pas exactement ce pour quoi SVN est conçu.
La manière SVN-miroir
Vous pouvez utiliser svn mirror comme expliqué dans la documentation du livre SVN pour créer un miroir en lecture seule de votre référentiel maître. Vos développeurs interagissent chacun avec le miroir le plus proche d'eux. Cependant, les utilisateurs du référentiel esclave devront utiliser
commutateur svn --relocate master_url
avant de pouvoir s'engager et ils devront se rappeler de se réinstaller sur l'esclave une fois qu'ils auront terminé. Cela pourrait être automatisé à l'aide d'un script d'encapsulation autour des commandes de modification du référentiel sur SVN si vous utilisez le client de ligne de commande. Gardez à l'esprit que l'opération de relocalisation à un rythme rapide ajoute un peu de surcharge. (Et faites attention à dupliquer l'uuid du référentiel - voir la documentation SVN .)
[Edit - En vérifiant la documentation TortoiseSVN il semble que vous pouvez avoir TortoiseSVN exécuter les scripts de hook côté client . À ce stade, vous pourrez peut-être créer un script de validation avant/après. Soit cela, soit essayez de voir si vous pouvez utiliser interface d'automatisation TortoiseSVN pour le faire].
La manière SVK
svk est un ensemble de scripts Perl qui émulent un service de mise en miroir distribué sur SVN. Vous pouvez le configurer de sorte que la branche locale (le miroir) soit partagée par plusieurs développeurs. Ensuite, l'utilisation de base pour les développeurs sera complètement transparente. Vous devrez utiliser le client svk pour la sélection, la fusion et la fusion de cerises. C'est faisable si vous pouvez vous familiariser avec les concepts distribués.
La manière git-svn
Même si je ne l'ai jamais utilisé moi-même, vous pouvez également demander à des développeurs distants d'utiliser git localement et d'utiliser la passerelle git-svn pour la synchronisation.
Mots finaux
Tout dépend de votre environnement de développement et du niveau d'intégration dont vous avez besoin. En fonction de votre IDE (et si vous pouvez modifier SCM ), vous voudrez peut-être jeter un œil à d'autres SCM entièrement distribués (pensez Mercurial / Bazaar / Git /...) qui prennent en charge le développement distribué hors de la boîte.
Vous devriez essayer Le système de contrôle de version SVK
SVK est un système de contrôle de version décentralisé construit avec le robuste système de fichiers Subversion. Il prend en charge la mise en miroir du référentiel, le fonctionnement déconnecté, la fusion sensible à l'historique et s'intègre à d'autres systèmes de contrôle de version, ainsi qu'aux outils de fusion visuels populaires.
Sur ce lien, il y a du texte sur tilisation de SVK pour synchroniser les référentiels SVN
Si l'un des référentiels est entièrement en lecture seule, vous pouvez utiliser 'svnsync' pour le maintenir à jour avec le référentiel maître. Cet outil est souvent utilisé en combinaison avec le support proxy pour créer une configuration maître-esclave.
Par exemple. Apache fait cela pour refléter leur référentiel sur différents continents. Le référentiel maître est situé aux États-Unis, mais si j'accède au référentiel depuis l'UE, j'obtiens un miroir local qui fonctionne aussi bien que le serveur maître.
Les outils inotify fonctionnent bien pour moi, les détails sont mentionnés sur ce site:
http://planet.admon.org/synchronize-Subversion-repositories-with-inotify-tools/
Il existe une solution commerciale qui fournit une véritable réplication active-active (pas maître-esclave) des référentiels Subversion si vous avez besoin de performances et de sécurité des données au-delà de ce que svnsync fournit appelé "Subversion MultiSite".
Avertissement: je travaille pour l'entreprise qui fabrique cette solution
Le serveur VisualSVN Multisite Repository Replication a été conçu pour ce cas.
Vous pouvez conserver le référentiel maître dans votre bureau principal et configurer plusieurs référentiels esclaves accessibles en écriture sur les sites distants.
Cela devrait fonctionner de la manière la plus transparente possible pour les développeurs. L'utilisabilité est un must.
La réplication entre les esclaves et le maître est transparente et automatique,
Chaque référentiel maître et esclave est un référentiel Subversion accessible en écriture du point de vue de l'utilisateur,
Fonctionne prêt à l'emploi et peut être configuré en quelques clics via VisualSVN Server Manager MMC.
