Comment obtenir une réplication maître-maître avec Subversion?

Question

Cela semble être un problème simple:

• J'ai un référentiel SVN à l'intérieur de notre pare-feu.
• J'ai un référentiel SVN en dehors de notre pare-feu.
• J'ai des utilisateurs à l'intérieur et à l'extérieur du pare-feu. (pas de VPN n'est pas une option :( ce serait trop facile)
Les
• ordinateurs situés à l'intérieur du pare-feu PEUVENT parler au serveur SVN extérieur. Mais pas l'inverse.
• le SVN extérieur est temporaire - le référentiel principal sera toujours à l'intérieur.

Je veux en quelque sorte (de l'intérieur, très probablement) prendre tous les changements dans l'un et les appliquer à l'autre. Et vice versa. Cela semble simple, et je suppose que GIT peut le faire, mais nous utilisons SVN.

Quelqu'un a fait ça? Cela ne me dérange pas qu'il s'agisse d'un processus manuel: il n'y a que deux personnes externes et elles n'ont pas besoin de mises à jour à la minute, deux ou trois fois par jour suffiraient.

Je pense qu'apache.org le fait, mais je ne trouve pas de documentation sur COMMENT ils le font. Il y a quelques produits sur le marché qui le font (bon, un), mais j'aimerais savoir si quelqu'un a une façon agréable et propre de le faire sans eux. svnsync fait cela, seulement dans un sens (maître-esclave)

Heureux de le faire fonctionner sous Windows, Linux ou Mac, car nous les avons tous. Windows et Mac préfèrent cependant.

Aide! :):)

[mise à jour] après 12 mois de bricolage (et n’en ayant plus besoin), la bonne réponse est, à mon avis, la bonne. Utilisez git - ayez un repo qui tire de SVN-A, puis poussez vers un nouveau repo git, puis poussez-le vers SVN-B. Devrait fonctionner:)

Answer 1

Je recommanderais SVK ou git-svn .

Ces deux options vous permettent de créer un miroir externe de votre référentiel svn et permettent aux développeurs externes de s’engager directement dans le miroir externe. Vous pouvez ensuite extraire et transférer les modifications de ce miroir externe vers votre dépôt principal interne.

git-svn nécessiterait (je pense) que les développeurs externes utilisent git. Je le préfère, mais je serais réticent à le faire subir à d’autres.

SVK, cependant, permet aux développeurs externes de continuer à utiliser svn. Le référentiel interne n'étant accessible qu'en interne, un compte ou un utilisateur interne devra gérer la synchronisation périodique (un travail cron fonctionnerait probablement).

Voici un tutoriel étendu sur le wiki SVK: UtiliserSVKAsARepositoryMirroringSystem

Answer 2

La simplicité est généralement la meilleure solution et vous semblez déjà disposer d'une solution simple: utilisez le référentiel SVN en dehors du pare-feu.

Vous avez déjà dit que les machines à l'intérieur du pare-feu peuvent l'atteindre, et bien sûr que les machines à l'extérieur peuvent l'atteindre ... c'est donc tout le monde, alors quelle justification avez-vous d'un deuxième référentiel SVN à l'intérieur du pare-feu? S'il ne s'agit que d'une sauvegarde, sauvegardez celle qui se trouve à l'extérieur.

Faites-moi savoir s'il me manque une partie de vos besoins.

Une autre pensée ... si vous avez à la fois des instances SVN internes et externes ... ce qui les empêche de donner le même ID de liste de modifications en même temps, à des fins différentes? Si vous recherchez une solution décentralisée, vous devriez vous tourner vers GIT plutôt que sur SVN.

Answer 3

Une des fonctionnalités de l'édition Enterprise de VisualSVN Server est la réplication de référentiel multisite qui fait exactement ce que vous recherchez.

Cette fonctionnalité est basée sur la technologie VDFS (VisualSVN Distributed File System), conçue pour permettre une réplication transparente du référentiel Subversion sur des sites répartis géographiquement. Certaines des caractéristiques notables de VDFS:

• Tous les référentiels VDFS Subversion distribués sont accessibles en écriture,
• VDFS permet une réplication de données bidirectionnelle transparente,
• VDFS prend en charge les règles d’autorisation de réplication et les mécanismes d’authentification avancés, tels que l’authentification Windows intégrée (NTLM / Negotiate) avec cryptage sécurisé SSL / TLS.
• Tous les référentiels VDFS contiennent le même jeu de données,
• La réplication du référentiel sur un réseau WAN avec VDFS est jusqu'à 10 fois plus rapide que la réplication basée sur un proxy en écriture directe,
• La configuration de VDFS se fait via une interface graphique sans aucune étape compliquée.

Il convient de noter que VDFS suit le modèle de réplication classique maître-esclave , qui présente des avantages considérables par rapport au modèle de réplication maître-maître , car il est plus adapté à la réplication de référentiels Subversion avec FSFS. backend de type fs. La technologie VDFS est beaucoup plus fiable que les solutions de réplication maître à maître pour SVN.

• Serveur VisualSVN | Configuration du référentiel multisites ,
• Comparaison de VDFS avec des solutions de réplication maître-maître .

Answer 4

Hmm ... je pense que garder deux pensions en synchronisation est non-trivial. Il s'agirait essentiellement de transformer SVN en Mercurial ou Git.

Answer 5

La solution la plus transparente et la plus évolutive est la réplication maître / esclave à l’aide de svnsync, décrite dans le livre Subversion: http://svnbook.red-bean.com/fr/1.7/svn-book.html#svn.serverconfig.httpd.extra.writethruproxy

Answer 6

Vous pouvez notamment essayer de répliquer le référentiel au niveau du fichier. J'utilise FolderShare ( http://www.foldershare.com - fonctionne sous Windows et Mac) pour une application similaire. scénario, bien que je le réplique uniquement à des fins de sauvegarde et que je n'ai pas essayé de me connecter à l'aide du SVN au réplica.

Answer 7

http://wandisco.com/subversion/multisite/

  

Subversion MultiSite exploite   Réplication unique de WANdisco   technologie pour synchroniser immédiatement   Dépôts Subversion connectés sur   un réseau étendu (WAN). Utilisateurs à   chaque lieu d'expérience expérience locale   performances de vitesse réseau (LAN) pour   les opérations de lecture et d'écriture.   Subversion MultiSite fournit également   sauvegarde à chaud continue et auto-guérison   des fonctionnalités qui automatisent les catastrophes   récupération, de sorte que le temps d'arrêt est   pratiquement éliminé.

Answer 8

Si vous recherchez une explication étape par étape sur la réplication maître / esclave à l'aide de svnsync, veuillez suivre les instructions http://lasanthals.blogspot.com/2012/09/main-steps-of-configuring-svn_4.html