Code in mehreren SVN-Servern halten

Question

Als freiberuflicher Entwickler behalte ich meine gesamte Entwicklung in meinem eigenen SVN-Server sowohl für die fortlaufende Integration als auch für die Buchführung darüber, welche Änderungen wann vorgenommen wurden.

Ich arbeite jetzt mit einem Kunden, der auch SVN intern verwendet und würde mich natürlich gerne mit ihrem Entwicklungsteam auf ihrem SVN-Server arbeiten.

Das ist im Allgemeinen toll, aber es würde auch dazu führen, dass ich meine Arbeitspraxis bei diesem Projekt aufgeben und meine interne Buchhaltungsmethode verlieren würde. Wenn das viel passiert, dann werde ich mit ziemlich lockeren Arbeitsstandards enden - am Ende variiert das Projekt (was ich natürlich nicht will).

Gibt es einen kreativen Weg, um das Beste aus beiden Welten zu erhalten, und der Code existiert beim Commit in beiden SVN-Servern? Es macht mir nichts, ein wenig mehr Arbeit vor oder bei jedem Commit/Update, um es abzuziehen.

svnsync sieht aus wie vielleicht eine gute Option. Hat jemand das versucht? Hat jemand andere Vorschläge?

Answer 1

Ich bin mir nicht sicher, was das Problem ist. Sie verwenden eine andere SVN URL, aber alles andere ist gleich. Was meinst du mit "Buchhaltung"?

Vielleicht läuft es darauf hinaus, wem der Code gehört - wenn sie es sind, haben sie jedes Recht, Sie zu bitten, ihr Versionskontrollsystem zu benutzen. Und da es sich anhört, als ob du mit einem Entwicklerteam arbeitest, hast du dich zahlenmäßig unterlegen.

Weil es andere Entwickler beteiligt sind, müssen Sie offensichtlich ihre Repository abarbeiten, um sicherzustellen, Sie immer den neuesten Code und damit Konflikte vermeiden, usw.

Wenn Sie sind besorgt über eine Kopie des Codes zu halten (Unter der Annahme, dass dies legal ist), gibt es viele Möglichkeiten, das zu erreichen, z. B. den Arbeitsordner, der auf ihren Server verweist, in einen anderen Arbeitsordner auf Ihrem Rechner zu exportieren und ihn zu committen.

Answer 2

Sie könnten das Repository Ihrer Kunden regelmäßig (wöchentlich?) Svndump und in Ihren eigenen Server importieren, damit Sie Ihre Analyse für Abrechnungszwecke oder andere durchführen können.

Das einzige Problem, an das ich denken kann, ist, wie glücklich Ihr Kunde für Sie sein könnte, dies zu tun.

Answer 3

Sicherlich unterstützt das Versionskontrollsystem die Freigabe und Verwaltung von Code. Wenn Sie zwei Repositories verwenden, werden die Dinge sehr schnell sehr unordentlich. Ich würde mit dem Fluss gehen und verwenden, was auch immer das Unternehmen Sie fragt

Answer 4

Ich kann hier zwei verschiedene Ansätze sehen, entweder Sie weiter in Ihrem Repository arbeiten und dann manuell Tropfen auf ihr Repository, wenn Sie glauben, dass Ihr Code ist Par. Der andere Ansatz wäre, svn commit hooks zu betrachten - d. H. Skripte, die ausgeführt werden, wenn ein Commit ausgeführt wird. Aus einem solchen Skript gehe ich davon aus, dass Sie das Commit für ein anderes Repository problemlos durchführen können.

Ich nehme an, dass Ihr Vertrag Ihnen erlaubt, den Code für sich selbst zu behalten, sonst müssen Sie ziemlich viel tun, was Ihr Kunde Ihnen mit dem Code sagt.

Answer 5

Wenn Sie nur die Änderungen in Subversion auflisten möchten (ich denke, Anzahl der Commits pro Woche, Liste der behobenen Probleme ...), könnten Sie eine einfache Java-Anwendung schreiben, die any abfragt Subversion-Repository für Ihre Änderungen. Danach müssen Sie nur Ihre Anwendung auf das richtige Repository zeigen.

Es gibt ein paar einfach zu bedienende Subversion-Bibliotheken und ich hatte kein besonderes Problem mit SvnKit.

Answer 6

Mit der Client-Repository

Eine Lösung wäre, nur direkt Ihre Kunden-Repository zu verwenden. Alle anderen "Sachen", die nicht dorthin gehören, die nur für Ihre Buchhaltung relevant sind, wie z. B. Projektmanagement, Zeitmessung usw., können in Ihrem lokalen Repository gespeichert werden. Sie würden die beiden getrennt halten, mit zwei separaten Arbeitskopien, obwohl Sie in Ihrem lokalen Repository eine svn:external einrichten könnten, die auf das Repository des Clients zeigt, wenn Sie ein wenig knifflig werden wollen.

Das sollte so lange funktionieren, wie sowohl Sie als auch der Client zufrieden damit sind, wie feinkörnig Ihre Commits sind. Sie können auch in Erwägung ziehen, in einem Zweig im Repository Ihres Kunden zu arbeiten und mit dem Stamm zu arbeiten, wenn Sie mit Ihrer Arbeit zufrieden sind. Es hat auch den Vorteil (für Ihren Kunden), dass der Kunde eine Sicherungskopie aller Ihrer laufenden Arbeiten hat, die ihm gefallen könnten.

git mit Subversion Integration

Eine andere Lösung könnte git sich lokal zu bedienen, und die Nutzung seiner ability to work with Subversion machen. Sie können Ihre Work-in-Progress in einem leichten lokalen Zweig halten.