Frage

Es scheint ein einfaches Problem:

  • Ich habe einen SVN Repo in unserer Firewall.
  • Ich habe ein SVN Repo außerhalb unserer Firewall.
  • Ich Benutzer haben innerhalb und außerhalb der Firewall. (Kein VPN ist keine Option :( das auch einfach sein würde)
  • Maschinen innerhalb der Firewall an den Außen SVN-Server sprechen. Aber nicht andersrum.
  • die außerhalb SVN ist eine vorübergehende Sache - die wichtigsten Repo immer drin sein
  • .

Ich möchte irgendwie (von innen, höchstwahrscheinlich) in einer alle Änderungen übernehmen und sie auf die andere Anwendung. Und umgekehrt. Klingt einfach, und ich nehme an, dass die Gleichen GIT dies tun können, aber wir SVN verwenden.

Wer das getan? Ich kümmere mich nicht es ein manueller Prozess sein -. Gibt es nur ein paar extern Leute, und sie brauchen kein Updates to-the-Minute, zwei oder drei Mal am Tag tun würde,

Ich glaube, apache.org dies tut, aber ich kann auf nicht docs finden, wie sie dies tun. Es gibt ein paar Produkte gibt, die es tun (na ja, ein), aber ich würde gerne wissen, ob jemand eine schöne, saubere Art und Weise hat es ohne sie zu tun. svnsync tut dies, gerade nur in einer Richtung (Master-Slave)

Happy es auf Windows, Linux oder Mac laufen zu lassen, wie wir alle von ihnen haben. Windows und Mac obwohl bevorzugt.

Hilfe! :):)

[Update] nach 12 Monaten Herumspielen (und das nicht am Ende brauchen), die richtige Antwort ist, meiner Meinung nach, zu korrigieren. Verwenden git - haben ein repo, die aus SVN-A zieht, drücken dann auf einen neuen git repo, dann schieben von dort zu SVN-B. Sollte funktionieren:)

War es hilfreich?

Lösung

Ich würde empfehlen, SVK oder git-svn .

Beide können Sie einen externen Spiegel Ihrer SVN-Repository erstellen und lassen Sie die externen Entwickler verpflichtet sich, dem externen Spiegel direkt zu machen. Sie können dann ziehen und schieben sie von diesem externen Spiegel zu Ihrem internen Master-Repo.

git-svn würde (glaube ich) erfordern die externen Entwickler git zu verwenden. Ich ziehe es, aber ich würde nur ungern diese auf andere schieben.

SVK erlaubt jedoch die externen Entwickler, die mit SVN fortzusetzen. Da die interne Repo nur intern zugänglich ist, wäre ein internes Konto oder Benutzer die periodische Synchronisation (ein Cron-Job wahrscheinlich funktionieren wird) behandeln.

Hier ist eine erweiterte howto auf der SVK wiki: UsingSVKAsARepositoryMirroringSystem

Andere Tipps

Einfachheit ist in der Regel die beste Art und Weise, und es klingt wie Sie bereits eine einfache Lösung hat. Verwenden Sie das SVN Repository außerhalb der Firewall

Sie haben bereits gesagt, Maschinen innerhalb der Firewall können es zu erreichen, und offensichtlich außerhalb Maschinen es erreichen können ... so dass jeder ist, also was Rechtfertigung haben Sie für einen zweiten SVN-Repository innerhalb der Firewall? Wenn es nur als Back-up ist, dann nur die eine auf der Außenseite Back-up.

Lassen Sie mich wissen, wenn ich ein Teil Ihrer Anforderungen bin fehlt.

Ein anderer Gedanke ..., wenn Sie sowohl interne als auch externe SVN-Instanzen haben ... was beide zu stoppen, ist ihnen die gleiche Änderungs ID zur gleichen Zeit heraus geben, für verschiedene Zwecke? Wenn Sie eine de-zentrale Lösung suchen, sollten Sie ihren Blick auf GIT statt SVN.

Eines der Merkmale der Enterprise Edition von VisualSVN Server ist Multisite Repository-Replizierung , die genau das tut, was Sie suchen.

Die Funktion basiert auf VisualSVN (Distributed File System VDFS) Technologie, die entwickelt wurde über geografisch verteilte Standorte transparent Subversion-Repository-Replikation zu ermöglichen. Einige der wichtigsten Merkmale von VDFS:

  • Alle verteilten VDFS Subversion-Repositorys sind beschreibbar,
  • VDFS ermöglicht eine transparente bidirektionale Datenreplikation,
  • VDFS unterstützt Replikation Autorisierungsregeln und erweiterte Authentifizierungsmechanismen wie integrierte Windows-Authentifizierung (NTLM / Verhandeln) mit sicheren SSL / TLS-Verschlüsselung.
  • Alle VDFS Repositories enthalten die gleiche Datenmenge,
  • Repository Replikation über WAN mit VDFS ist bis zu x10 schneller als die Replikation basiert auf Write-Through-Proxy,
  • VDFS Konfiguration über eine grafische Oberfläche ohne komplizierte Schritte durchgeführt wird.

Es ist erwähnenswert, dass VDFS das klassische folgt Master-Slave Replikationsmodell, das über bedeutende Vorteile hat Master-Master Replikationsmodell, weil es für die Replikation von Subversion-Repositorys mit FSFS besser geeignet ist fs-Typ-Backend. VDFS Technologie ist viel zuverlässiger als Master-Master-Replikationslösungen für SVN.

VDFS Konfigurationsschnittstelle für mehrere Standorte Apache SVN repos

Hmm ... halten zwei repos synchron miteinander ist nicht trivial, denke ich. Es würde bedeuten, im Grunde SVN in Mercurial oder Git drehen.

Die nahtlose und skalierbare Lösung ist der Master / Slave-Replikation svnsync verwenden, die in dem Subversion Buch beschrieben wird: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.httpd.extra.writethruproxy

Eines könnte man versuchen, die Repo auf Dateiebene zu replizieren. Ich bin mit Folder ( http://www.foldershare.com - läuft unter Windows und Mac) für ein ähnliches Szenario, obwohl ich es nur für Backup-Zwecke am replizieren und habe versucht, nicht auf die Replik mit SVN zu verbinden.

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

  

Subversion Multisite Hebel   WANdisco einzigartige Replikation   Technologie sofort zu synchronisieren   Subversion-Repositorys verbunden über   ein Weitverkehrsnetz (WAN). Benutzer an   jeder Standort Erfahrung Umgebung   Netzwerk (LAN) für die Geschwindigkeitsleistung   Lese- und Schreiboperationen.   auch Subversion Multisite bietet   kontinuierliche Hot-Backup und Selbstheilung   Fähigkeiten, die Katastrophe zu automatisieren   Erholung, so dass Ausfallzeiten   praktisch ausgeschlossen.

Wenn Sie Schritt suchen Schritt Erklärung über Master / Slave-Replikation svnsync verwenden, folgen Sie http://lasanthals.blogspot.com/2012/09/main-steps-of-configuring-svn_4.html

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top