Wie vermeide ich komplizierte Zusammenführungen in Subversion?

Ich bin auch ein ehemaliger Visual Source Safe-Benutzer. Fusionen haben mich verrückt gemacht, bis ich gemerkt habe, dass es kein technologisches Problem ist, sondern ein Problem der Menschen. Bei der Verwendung von VSS versuchen die meisten Entwickler, so viel Arbeit wie möglich zu erledigen, bevor sie Code einchecken müssen. Dieses Verhalten hat zu komplizierten Zusammenführungen beigetragen.

Hier sind ein paar Dinge, um dies zu mildern:

• Aktualisieren Sie Ihre Arbeitskopie immer vor dem Start
• Check-in oft. Dadurch werden die Codeänderungen kleiner, was das automatische Zusammenführen von
erleichtert
• Lassen Sie Arbeitscode nicht deaktiviert werden
• Entwickler sollten ihre eigene Zweigstelle erstellen, wenn die Änderungen mehrere Tage oder länger dauern

Diese Dinge haben enorm geholfen, vor allem, weil die Teams, in denen ich arbeitete, immer größer wurden. Die Replizierung des Sperrverhaltens von VSS ist eine sehr schlechte Idee und wird weitere Probleme verursachen. Umarmen Sie einfach den neuen Workflow.

Wenn Sie immer noch ein Tool verwenden möchten, schlage ich vor, dass Sie sich SVNMonitor ansehen.

Ich würde vorschlagen, einen anderen Ansatz zur Verwendung von Subversion zu wählen.

• Sie sollten regelmäßig Updates erhalten.
• Sie sollten auch früh und oft einchecken.

Bei diesem Ansatz ist das Zusammenführen in der Regel selten und geschieht automatisch. Im Falle von Konflikten sind diese oft kleiner.

Ein paar Punkte, denen ich an einem früheren Ort begegnete, wo wir von einem Lock-basierten System zu SVN gingen.

Es ist nicht wirklich eine gute Idee, das Sperr-Edit-Entriegelungs-Verhalten in SVN zu replizieren, da es so entworfen wurde, dass Sie nicht auf diese Weise arbeiten müssen. Die von SVN verwendeten Zusammenführungsalgorithmen sind ziemlich gut und ich habe nur einige Vorkommnisse erlebt, bei denen manuelles Eingreifen während einer Zusammenführung erforderlich war. Es ist überraschend selten, dass zwei Personen, die an der gleichen Datei arbeiten, die gleiche (n) Zeile (n) berühren und letztere oft die einzige Zeit ist, in der man manuell eingreifen muss.

SVN wurde entwickelt, um in einer Umgebung verwendet zu werden, in der Sie häufig von der Amtsleitung oder Ihrem aktuellen Zweig aus aktualisieren. Wenn Sie längerfristige Arbeiten oder Arbeiten durchführen müssen, die viel Code in einer Datei ändern, ist es besser, wenn Sie einen Zweig verwenden, um die Arbeit zu erledigen und diesen wieder zusammenzuführen. Ja, Sie müssen eine Zusammenführung durchführen Schmerz von Zeit zu Zeit, aber es ist erheblich weniger Schmerzen als Sie mit einem System, das nicht so entworfen wurde, um so zu arbeiten.

Wenn Sie versuchen, SVN nicht als "natives SVN", sondern als VSS mit einem anderen Namen zu verwenden, wird es schmerzhaft sein und es wird sich nicht lohnen. Machen Sie sich mit dem neuen Paradigma vertraut und Sie werden überrascht sein, wie viel schöner es ist, so zu arbeiten, als mit der alten Routine "nur ein Benutzer bearbeitet eine gegebene Datei zu einer bestimmten Zeit".

Zunächst ist es wahrscheinlich ratsam, möglichst wenig "Tonnen und Tonnen von Code" zu schreiben, ohne die Dateien zu überprüfen. Wenn Sie eine gute Komponententestsuite haben (und wenn nicht, warum nicht? :), dann sind häufige Commits am besten, solange Sie in der grünen Leiste einchecken.

Wenn Änderungen notwendig sind, die sehr lange dauern, lohnt es sich, regelmäßig svn update zu verwenden, um möglichst synchron mit dem Stamm zu bleiben. Subversion ist bei der Zusammenführung ziemlich respektabel (verglichen mit VSS) und wird die meisten Dinge gut bewältigen.

Alles, was nicht behandelt werden kann, wird in einen Konfliktzustand versetzt und Sie können die Konflikte mit einem Merge-Tool Ihrer Wahl lösen (ich empfehle WinMerge Dafür ist es ace).

Sie können das alte VSS-Stil-Sperrmodell nur mit Binärdateien (MS-Word-Dokumente usw.) verwenden, die Sie versionieren möchten, aber SVN kann Änderungen aus mehreren Quellen nicht automatisch zusammenführen. p>     

Kein Problem. Verwenden Sie Tortoise SVN, tun Sie dies ...

1. Klicken Sie im Windows Explorer mit der rechten Maustaste auf Datei (en).
2. Wähle "Tortoise SVN" und dann "Get Sperren ... "
3. Füllen Sie im Dialogfeld "Dateien sperren" aus in Ihrem Grund für das Schloss.
4. Klicken Sie auf OK.

Obwohl SVN einen Befehl lock hat, ist der optimistischste Ansatz zum Sperren der am häufigsten verwendete Weg zur Verwendung von SVN.

Das bedeutet, dass Sie und ich dieselbe Datei bearbeiten können und sich nicht viel Sorgen machen (meistens werden wir das nicht tun, weil wir an verschiedenen Teilen unseres Projekts arbeiten würden). Wenn ich zuerst Änderungen an der Datei festlege, schlägt Ihr Commit-Versuch fehl. Das ist, wenn SVN Sie benachrichtigen wird.

Sie müssen dann den "Update" -Befehl ausführen, der (wahrscheinlich) automatisch meine festgeschriebenen Änderungen mit Ihren lokalen Änderungen zusammenführt und dann Ihren nächsten Commit-Versuch durchläuft.

Um zu vermeiden, mit diesem optimistischen Ansatz in Schwierigkeiten zu geraten: wie andere vorgeschlagen haben, begehen Sie oft und verpflichten Sie nicht zu viel auf einmal!

  

SVN ist ein simultanes Modell, das es mehreren Personen erlaubt, an der gleichen Datei zu arbeiten und später die Änderungen zusammenzuführen.

Ich denke, es geht mehr darum, an demselben Projekt zu arbeiten, das aus einer Reihe von mehr oder weniger unabhängigen Dateien besteht. Das Arbeiten an der gleichen Datei und das Zusammenführen der Ergebnisse ist sicherlich möglich und kommt immer wieder vor, aber es ist definitiv nicht der Standard / gewünschte Betriebsmodus. Also:

• Häufig aktualisieren.
• Commit oft.
• Vermeide große Klassen / Dateien (1000 Zeilen sind viel zu viel). Dies hat auch zusätzliche Vorteile: -)

Ich würde etwas Zeit brauchen, um über den "Check-in-Tanz" zu lernen.

Hier ist eine Groschenbesetzung .

Es gibt auch mehrere Artikel im Internet darüber und wie man die Schmerzen lindert.

Kurze Antwort:

1. Aktualisierung oft. Check-in früh, Check-in oft. Wenn Sie länger an etwas arbeiten (mehr als ein oder zwei Tage), sollten Sie einen Feature-Zweig erstellen.
2. Nein.

Etwas längere Antwort:

Wenn mehr als ein Entwickler "Tonnen und Tonnen von Änderungen" an der gleichen Datei ausführt, ist etwas mit der Arbeitsweise der Entwickler oder mit der Art und Weise, wie Features über verschiedene Dateien verteilt werden, nicht einfach. Ich habe mit CVS und SVN in Teams unterschiedlicher Größe und IME gearbeitet. Es gibt nur sehr wenige Fälle, in denen das Zusammenführen zu einem echten Problem wird. (Dies sind in der Regel Änderungen der grundlegenden Dienste wie String, Logging, Fehlerbehandlung usw., die fast jeden Code ändern müssen. Solche Fälle erfordern einige menschliche Interaktion und Planung, um reibungslos zu funktionieren.)

Ich stimme allen anderen zu, so weit wie möglich früh und oft einchecken (es ist nicht immer möglich). Wenn Sie etwas Komplexes und Neues machen, können Sie es auf einer Zweigstelle machen - es gilt die gleiche Regel, Sie verpflichten sich früh und oft und halten Ihre Zweigstelle so aktuell wie möglich, mit Code aus dem Kopf.

Nach unserer Erfahrung neigen die Leute dazu, nicht zur selben Zeit an der gleichen Datei oder dem gleichen Teil der Datei zu arbeiten (in VSS konnte nicht funktionieren ) Muster unterstützen dich wahrscheinlich schon dabei.)

Eine weitere wichtige Sache - stellen Sie sicher, dass jeder die gleichen Regeln für die Verwendung von Tabs / Spacing verwendet, für Layout und Formatierung, dies ist sowieso eine gute Übung, aber je konsistenter Sie sind, desto weniger wahrscheinlich finden Sie "Unterschiede "zwischen Code-Dateien, die nicht wirklich existieren.

Außerdem würde ich Ihnen empfehlen, auf kontinuierliche Integration zu achten, dh auf einen Build-Server. Dies bietet erhebliche Vorteile in Bezug auf die Sicherheit, dass Ihr festgelegter Code in einer "sauberen" Umgebung erstellt wird und, wenn Sie mit Tests ausgestattet sind. gibt Ihnen noch mehr Sicherheit, dass es auch nach einem komplexen Merge-Prozess noch funktioniert.

Wir verwenden TeamCity , die wir für hervorragend befunden haben - aber es gibt noch andere.