Was ist so schwierig an SVN-Zusammenschlüssen?

28

Mögliches Duplikat:
Ich bin ein Subversion-Freak. Warum sollte ich Mercurial oder Git oder ein anderes DVCS in Betracht ziehen oder nicht?

Hin und wieder hört man jemanden sagen, dass die verteilte Versionskontrolle (Git, HG) von Natur aus besser ist als die zentralisierte Versionskontrolle (wie SVN), da das Zusammenführen in SVN schwierig und schmerzhaft ist. Die Sache ist, ich hatte nie Probleme mit dem Zusammenführen in SVN, und da Sie immer nur die Behauptung von DVCS-Befürwortern und nicht von tatsächlichen SVN-Nutzern hören, erinnert es mich eher an diese abscheulichen Werbespots im Fernsehen, in denen sie auftreten Versuchen Sie, etwas zu verkaufen, das Sie nicht brauchen, indem Sie sich von verrückten Schauspielern vortäuschen lassen, dass das, was Sie bereits haben und gut funktionieren, unglaublich schwer zu benutzen ist.

Und der Anwendungsfall, der immer wieder auftaucht, ist das Zusammenführen einer Filiale, was mich wieder an diese Strawman-Produktwerbung erinnert. Wenn Sie wissen, was Sie tun, sollten Sie eine Zweigstelle überhaupt nicht wieder zusammenführen (und sollten es auch nie müssen). (Natürlich ist es schwierig zu tun, wenn du etwas grundsätzlich Falsches und Dummes tust!)

Abzüglich des lächerlichen Strawman-Anwendungsfalls: Was ist beim Zusammenführen von SVN von Natur aus schwieriger als beim Zusammenführen in einem DVCS-System?

Mason Wheeler
quelle
6
Ich muss noch in einer Umgebung arbeiten, in der monatelange Zweige zusammengeführt werden und die eine verteilte Versionskontrolle verwenden. Die einzigen Orte, an denen ich gearbeitet habe, an denen so langlebige Zweige TFS / Subversion verwendeten. Ich gehe davon aus, dass es schwierig sein wird, so langlebige Zweige mit DVCSes zu verschmelzen.
Oded
13
@ MasonWheeler Ich bin verwirrt. Wofür verwenden Sie dann ein VCS? Ich habe gesehen und gelesen, dass eine (der vielen) empfohlenen Methoden darin besteht, Feature-Zweige zu haben. In diesem Fall ist das Zusammenführen zurück zum Trunk obligatorisch. Oder habe ich etwas falsch verstanden? (Ja, die Baummetapher bricht, aber es war nicht allzu nützlich, um mit IMO zu beginnen)
Andres F.
9
@ MasonWheeler: Ich denke, Sie nehmen die Baumanalogie ein bisschen zu wörtlich.
Whatsisname
8
@MasonWheeler Mit wie vielen verschiedenen Entwicklungsumgebungen haben Sie Erfahrung, wenn Sie noch nie davon gehört haben, wieder zum Trunk zusammenzuführen? Einige Läden haben einen stabilen Stamm und Versuchszweige. In diesem Fall ist es eine regelmäßige Veranstaltung, erfolgreiche Kirschernte wieder im Stall zu betreiben.
itsbruce

Antworten:

25

Dies liegt daran, dass svn nicht über die richtigen Datenstrukturen verfügt, um den letzten gemeinsamen Vorfahren der beiden Zweige genau zu bestimmen. Dies ist keine große Sache für eine Niederlassung, die nur einmal zusammengeführt wird, kann jedoch in Situationen, in denen mehrere Niederlassungen mehrmals zusammengeführt werden, zu vielen fehlerhaften Zusammenführungskonflikten führen.

Ich verfolge svn nicht sehr genau, aber ich verstehe, dass diese speziellen technischen Probleme in den letzten Versionen behoben wurden. Es war jedoch nicht früh genug, um den Mythos zu zerstreuen, und Leute, die DVCS für die Zusammenführung ausprobiert haben, sind aus anderen Gründen dabei geblieben.

Karl Bielefeldt
quelle
46

Wenn Sie wissen, was Sie tun, sollten Sie eine Zweigstelle überhaupt nicht wieder zusammenführen (und sollten es auch nie müssen). (Natürlich ist es schwierig zu tun, wenn du etwas grundsätzlich Falsches und Dummes tust!)

Und darin liegt die Quelle Ihrer Verwirrung und des gesamten Problems im Allgemeinen.

Sie sagen, dass das Zusammenführen von Zweigen "grundsätzlich falsch und albern" ist. Nun, genau das ist das Problem: Sie stellen sich Filialen als Dinge vor, die nicht zusammengeführt werden sollten. Warum? Weil Sie ein SVN-Benutzer sind, der weiß, dass das Zusammenführen von Zweigen schwierig ist . Deshalb tust du es niemals und ermutigst andere, es nicht zu tun. Sie wurden geschult , um eine Verschmelzung zu vermeiden. Sie haben Techniken entwickelt, mit denen Sie das Zusammenführen vermeiden .

Ich bin ein Mercurial-Benutzer. Selbst in meinen eigenen Projekten, in denen ich der einzige Entwickler bin, füge ich ständig Filialen zusammen . Ich habe einen Release-Zweig, in den ich einen Fix eingefügt habe. Nun, ich füge das wieder in die Hauptzeile ein, damit der Fix dort ankommt.

Wenn ich SVN verwenden würde, würde ich eine völlig andere Struktur der Codebasis annehmen. Warum? Weil SVN Zusammenführungen schwierig macht und Sie daher Redewendungen und Techniken entwickeln, um komplexe Zusammenführungen zu vermeiden .

DVCS machen komplexe Zusammenführungen einfach, da sie der Standardzustand sind . Alles ist mehr oder weniger ein Zweig in einem DVCS. Ihre gesamte Struktur ist also von Grund auf neu aufgebaut, um das Zusammenführen zu erleichtern. Auf diese Weise können Sie einen Workflow entwickeln, der täglich zusammengeführt wird, und nicht den SVN-Workflow, bei dem Sie niemals zusammengeführt werden.

Die einfache Tatsache ist: Sie sollten sich einem DVCS auf eine andere Weise nähern als SVN. Sie sollten die richtigen Redewendungen für diese sehr unterschiedlichen Arten von Versionskontrollsystemen verwenden. In SVN verwenden Sie Redewendungen, bei denen keine Zusammenführung erforderlich ist, da Zusammenführungen schwierig sind. In DVCS übernehmen Sie Redewendungen, die häufig Zusammenführungen verwenden, weil sie keine große Sache sind.

Richtiges Werkzeug für den richtigen Job.

Die Sache ist, dass der zusammenführungsorientierte Workflow viel besser und einfacher zu verwenden ist als der Workflow im SVN-Stil, bei dem Sie keine Dinge zusammenführen. Es ist einfacher zu sehen, wann etwas aus dem Release-Zweig in den Dev-Zweig gebracht wurde. Es ist einfacher, die verschiedenen Wechselwirkungen zwischen Zweigen zu erkennen. Es ist einfach, Testzweige für Dinge zu erstellen und diese dann abzuschneiden, wenn der Test nicht funktioniert. Und so weiter.

Wirklich, Joel erklärt das viel besser als ich . Du solltest das gut lesen.

Nicol Bolas
quelle
2
Im Gegenteil, ich wurde nie "geschult", um das Zusammenführen von Zweigen zu vermeiden. Es ist einfach etwas, das mir ehrlich gesagt nie in den Sinn gekommen ist, bis ich angefangen habe, DVCS-Leute darüber zu sprechen, und meine unmittelbare Reaktion war (und ist immer noch) "Was, bist du verrückt oder so?"
Mason Wheeler
14
@Mason: Wie ist das nicht Training? Sie wurden für die Verwendung von SVN im SVN-Stil geschult. Und der SVN-Stil besteht darin , das Zusammenführen nicht zu verwenden. Sie wurden also geschult, Dinge nicht zu verwenden oder gar in Betracht zu ziehen, sie zu verschmelzen. Deshalb ist es dir nie in den Sinn gekommen; weil Sie ein System verwendet haben, das es schwierig macht.
Nicol Bolas
5
Es gibt einen großen Unterschied zwischen "nicht trainiert" und "nicht trainiert".
Mason Wheeler
7
@ MasonWheeler: Nein, gibt es nicht. Wenn Sie nicht richtig unterrichtet werden, wie man etwas macht, dann sind Sie implizit geschult, es nicht zu tun. Es ist nicht in Ihrem Redewendungsrepertoire, mit dem Sie ein Problem lösen können. Daher können Sie es nicht zum Lösen von Problemen verwenden. Der Effekt unterscheidet sich nicht von der Anweisung, nicht zu verschmelzen, denn selbst wenn Sie es wollten, wissen Sie nicht, wie. Die Art und Weise, wie Sie ein gutes Argument als "denselben müden alten Boden" abtun, ist ein Beweis dafür. Sie denken nicht an das Zusammenführen als Werkzeug. Sie sehen es als Ausnahme oder etwas Ungewöhnliches. Etwas, das eher in Frage gestellt als benutzt werden sollte.
Nicol Bolas
8
@MasonWheeler: Wer bist du, um zu entscheiden, "dass sie es falsch machen "? Sie verwenden keine DVCSs, haben also keine Erfahrung mit dem DVCS-Workflow. Sie haben keine Ahnung, ob es für Programmierer hilfreich ist oder nicht, da Sie keine Erfahrung damit haben. Also, welche Autorität haben Sie zu sagen, dass es "falsch" ist, nur weil SVN es nicht erlaubt? Es ist wie zu sagen, dass Klassen, virtuelle Funktionen und Vorlagen falsch sind, weil C sie nicht hat.
Nicol Bolas
20

Das Zusammenführen von SVN ist nicht allzu schwierig, wenn Sie der richtigen Philosophie folgen

Was ich in den meisten anderen Antworten sehe, scheint von Leuten zu kommen, die SVN eine Weile nicht mehr benutzt haben. Wie jemand genau erwähnt: "Es war nicht früh genug behoben, um den Mythos zu zerstreuen".

Aufgrund meiner derzeitigen Erfahrung mit der Verwendung von SVN 1.6 bis 1.8 in einem Vorgängerprojekt, das ich kürzlich geerbt habe, hat SVN das Zusammenführen erheblich vereinfacht. Es ist jedoch nicht narrensicher, und ich denke, es leidet nicht leicht unter Benutzern, die von der beabsichtigten Verwendung abweichen.

Obwohl ich SVN ziemlich gut kannte und Mercurial in der Zwischenzeit auch für persönliche Projekte ausprobiert hatte, hatte ich vor diesem Projekt noch nie viel in SVN verzweigt. Es gab einiges an Versuch und Irrtum und ich bekam eine Menge unerwarteter Zusammenführungskonflikte, als ich anfing.

Letztendlich wurde mir jedoch klar, dass ich jedes Mal, wenn ich eines (oder ein anderes Problem) bekam, Dinge nicht richtig gemacht hatte (auch bekannt als "der SVN-Weg" - wohl der richtige Weg zur Versionskontrolle). Ich glaube, hier liegt die Schwierigkeit: Sie können nicht auf unorganisierte Weise tun, was Sie wollen, und erwarten, dass SVN perfekt funktioniert, insbesondere bei Zusammenführungen. Zusammenführungen erfordern von den Benutzern strenge Disziplin, bevor sie ihre wahre Kraft entfalten können.

Folgendes ist mir aufgefallen: Es gibt starke Empfehlungen, wenn nicht sogar Anforderungen, für eine saubere Verwendung von Zusammenführungen:

  • Verwenden Sie eine neuere Version von SVN (1.6 oder höher, meiner Meinung nach). Immer mehr Automatisierungen und Überprüfungen werden für Sie durchgeführt.
  • Verwenden Sie die Standardstruktur "trunk, branches, tags" und wenden Sie deren Philosophie an (verpflichten Sie sich nicht zu Tags). SVN überprüft nichts für Sie. Wenn Sie ein Tag als Zweig verwenden (das ist der Zustand, in dem ich das Projekt-Repository gefunden habe), kann es weiterhin funktionieren, aber Sie müssen konsistent sein.
  • Wissen, was Zweige sind und wann sie erstellt werden müssen. Das gleiche gilt für Tags.
  • Halten Sie die Nebenzweige mit ihrem Quellzweig auf dem neuesten Stand (normalerweise Trunk, aber Sie können technisch von jedem Zweig aus verzweigen). Dies ist obligatorisch, wenn SVN automatisch zusammengeführt werden soll. SVN 1.8 verhindert, dass Sie automatisch zusammengeführt werden, wenn die Dinge nicht auf dem neuesten Stand sind, und auch, wenn Änderungen in Ihrer Arbeitskopie ausstehen (dieses Verhalten scheint in 1.8.5 wieder verschwunden zu sein).
  • Machen Sie "richtige" Commits. Sie sollten nur Änderungen an einem bestimmten Konzept enthalten. Sie sollten möglichst wenig Veränderung enthalten. Sie möchten nicht , dass ein einzelnes Commit Änderungen für zwei unabhängige Fehler enthält. Wenn Sie beide Probleme bereits behoben haben und sie sich in derselben Datei befinden, sollten Sie die Änderungen eines Fehlers wegspeichern, damit Sie nur die Änderungen des anderen zuerst festschreiben und dann den zweiten Änderungssatz festschreiben können. Beachten Sie, dass TortoiseSVN dies einfach über "Nach Commit wiederherstellen" ermöglicht.
    • Auf diese Weise können Sie eine bestimmte Gruppe unabhängiger Änderungen rückgängig machen UND eine solche Gruppe nur in einem anderen Zweig zusammenführen. Ja, mit SVN können Sie ausgewählte Revisionen zusammenführen.
  • Wenn Sie jemals Unterzweige verwenden (Verzweigung von Trunk, dann Verzweigung von diesem neuen Zweig), beachten Sie die Hierarchie. Wenn Sie den Unterzweig mit dem Stamm aktualisieren oder umgekehrt, haben Sie Schmerzen. Zusammenführungen sollten in der Hierarchie nach unten oder oben kaskadiert werden.
    • Nach ein paar Monaten des Experimentierens kann ich bezeugen, dass dies der wichtigste Teil sein könnte. Es wurde versucht, zwei Unterzweige aus demselben Stamm zu erstellen und dann Bits zwischen den Unterzweigen oder manchmal zwischen Unterzweigen von beiden Seiten zusammenzuführen. Dies kann SVN (oder den Benutzer) auslösen. Es kann einwandfrei funktionieren, wenn Sie bestimmte Revisionen zusammenführen. Die automatische Zusammenführung kann Probleme verursachen.
    • Ich hatte speziell Probleme beim Synchronisieren von Unterzweig A mit Trunk und beim Versuch, etwas von Unterzweig A in Unterzweig B zusammenzuführen. SVN scheint der Meinung zu sein, dass die Revision "Synchronisieren von Trunk" legitimerweise in Unterzweig zusammengeführt werden sollte B und dies führt zu einer Masse von Konflikten.
  • Führen Sie so viel wie möglich von der Wurzel des Zweigs aus zusammen. Andernfalls wird SVN halten nur den Überblick über die für den Unterordner getan verschmilzt , und wenn Sie tun , versuchen Auto-Merge von der Wurzel, können Sie Warnungen über fehlende unmerged Revisionen erhalten. Es kann behoben werden, indem diese einfach aus dem Stammverzeichnis zusammengeführt werden. Vermeiden Sie jedoch am besten die Verwirrung.
  • Achten Sie darauf, in welchem ​​Zweig Sie sich engagieren. Wenn Sie Switch verwenden, damit Ihre Arbeitskopie im Laufe der Zeit auf verschiedene Zweige verweist, stellen Sie sicher, wo Sie sich festlegen.
    • Es ist besonders schlimm, wenn Sie die Veränderung in dieser Branche wirklich nicht wollten . Ich bin mir immer noch nicht sicher, aber je nachdem, wie Sie es loswerden / in den richtigen Zweig übertragen (rückgängig machen, verschmelzen), können Sie etwas Unordentliches bekommen. Es ist reparabel, aber Sie müssen entweder Revision für Revision zusammenführen, um potenzielle Konflikte zu vermeiden oder umgehend zu lösen, oder Sie müssen nach dem automatischen Zusammenführen einen möglicherweise komplexeren Konflikt beheben.
  • Halten Sie die Zweige nicht zu lange unberührt. Eigentlich ist es keine Frage der Zeit, sondern wie viele Überarbeitungen an Zweig und Stamm vorgenommen wurden und wie viel sich in diesen geändert hat. Zusammenführungen zwischen zwei Zweigen, 3-Wege-Zusammenführungen, werden immer mit der letzten gemeinsamen Revision zwischen den Zweigen verglichen. Je mehr Änderungen dazwischen liegen, desto mehr Änderungen schlägt die automatische Zusammenführung fehl. Dies ist natürlich viel schlimmer, wenn Sie in der Zwischenzeit die Struktur Ihres Codes geändert haben (verschobene oder umbenannte Dateien).

Wenn Sie die obigen Anweisungen nicht befolgen, können Konflikte auftreten. Sie sind immer lösbar, aber es macht keinen großen Spaß, Zeit damit zu verbringen.

Oh, noch eine Sache beim Zusammenführen, wo SVN von allem, was ich gelesen und ausprobiert habe, wirklich scheiße ist: gelöschte / verschobene / umbenannte Dateien / Ordner. Anscheinend kann SVN immer noch nicht damit umgehen, dass eine Datei in einem Zweig umbenannt, gelöscht oder verschoben und ihre ursprüngliche Version in einem anderen Zweig geändert wird ... und diese dann zusammengeführt werden. Es wird einfach nicht wissen, wohin die Datei in der einen Richtung verschoben wurde, und es wird die Änderungen in der anderen Richtung "vergessen". Eine Änderung ist offensichtlich nicht lösbar (Sie können die Datei entweder löschen oder ändern, nicht beides), aber das Anwenden von Änderungen auf verschobene / umbenannte Dateien sollte funktionieren und funktioniert nicht. Hoffentlich wird das bald behoben.

Alles in allem ist es also einfach, SVN zusammenzuführen? Ich denke nicht. Auf keinen Fall sorglos. Ist es schlecht ? Ich glaube nicht. Es spuckt dir nur ins Gesicht, wenn du es falsch benutzt und nicht genug darüber nachdenkst, was du tust.

Auf dieser Grundlage kann ich sehen, warum die Leute Mercurial (zum Beispiel) bevorzugen, da es meiner Erfahrung nach etwas nachgiebiger ist und alles von Anfang an automatisiert wurde (zumindest seit den frühen Versionen, mit denen ich angefangen habe). SVN hat jedoch einiges aufgeholt, so dass es nicht mehr so ​​viel Bashing wert ist.

Leokhorn
quelle
Baumkonflikte - ja, SVN hat Schwierigkeiten damit, obwohl TBH dies auch bei jedem anderen SCM tut. Git hat einige Heuristiken, um herauszufinden, ob Dateien, die umbenannt oder verschoben wurden, gleich sind, aber es stimmt nicht (kann nicht!) Immer. Ich denke, SVN sollte einige Anstrengungen unternehmen, um die Lösung dieser Konflikte verständlicher zu machen.
Gbjbaanb
@gbjbaanb: Es bietet "Repair Move" wie Mercurial, obwohl es keine Heuristik bietet. Sie müssen angeben, welche gelöschten und hinzugefügten Dateien tatsächlich identisch sind. Auf jeden Fall Raum für Verbesserungen.
Leokhorn
All dies klingt großartig, wenn Sie die einzige Person sind, die an dem Projekt arbeitet ... Aber wenn Sie ein Team von guter Größe haben und es alle auf die "SVN-Art" verwenden (worüber sich offenbar niemand einig ist), verschmilzt dies sind immer noch eine PITA. Tatsache ist, dass svn den Verzweigungsworkflow nicht so gut unterstützt. Der "SVN-Weg" wäre, nicht einmal Zweige anzulegen und einen Wasserfall-SDLC zu verwenden. Abgesehen davon hatte ich in der Vergangenheit Probleme mit Git-Merges bei großen Projekten, bei denen mehrere Leute daran arbeiteten. Aber sie schienen immer noch viel weniger schmerzhaft zu sein.
Ryoung
Ich habe die Erfahrung gemacht, dass SVN von Tag zu Tag einfacher zu verwenden ist, wenn Sie mit Leuten zusammenarbeiten, denen die Funktionsweise des Versionskontrollsystems egal ist. Ich habe nur in einigen DVCS-Teams gearbeitet, aber ausnahmslos einige der Teams haben kein gutes Verhalten bei der Versionskontrolle und belasten das Repository für alle. In Subversion halten sich die Ungeübten in der Regel von Zweigniederlassungen fern, damit sie von den "Experten" beauftragt werden, dies für sie zu tun, und werden entsprechend verwaltet. Zugegeben, diese Erfahrung ist meine, und ich würde es vorziehen, nur mit Programmierern zu arbeiten, die wussten, wie ihre Werkzeuge funktionieren ...
Dash-Tom-Bang
5

Die internen Datenmodelle unterscheiden sich grundlegend.

Grundsätzlich sehen Sie in SVN, wenn Sie sich die Geschichte eines Zweigs ansehen, nur, was in diesem Zweig passiert ist. Wenn Sie also von Zweig Bzu Zweig zusammenführen A, enthält der Zweigverlauf Aein großes Commit, das alle Änderungen enthält , die seit der Verzweigung explizit vorgenommen wurden B.

In den ersten SVN-Versionen mussten Sie, wenn Sie Zweig erneut Bin Zweig zusammenführen Amussten, manuell angeben, welcher Versionsbereich des Zweigs Bzusammengeführt werden soll, um zu vermeiden, dass dieselben Versionen zweimal zusammengeführt werden. Der clevere Entwickler würde natürlich eine Commit-Nachricht wie "Merged in B: 1234" verwenden.

SVN 1.5 "reparierte" dies. Die grundsätzliche Anwendung von Zusammenführungen hat sich jedoch nicht geändert. Der Verzweigung Awurden lediglich einige zusätzliche Metadaten hinzugefügt , sodass SVN wusste, dass die Revision 1234 zusammengeführt wurde, und SVN automatisch den richtigen Revisionsbereich auswählte.

Diese Lösung ist jedoch im Grunde eine Problemumgehung für ein Datenmodell, das das Verfolgen von Zusammenführungen im Grunde nicht unterstützt.

Das Zusammenführen zweier Zweige ist ein relativ einfaches Beispiel. Aber dieses komplexere Szenario abbilden

  1. Erstellen Sie eine Verzweigung Avon trunkund machen Sie hier einige Festschreibungen
  2. Erstellen Sie einen Zweig Bvon Aund machen Sie hier ein paar Commits
  3. Machen Sie ein paar Commits in trunkundA
  4. Zusammenführen Bintrunk
  5. Zusammenführen AinB
  6. Zusammenführen Aintrunk
  7. Zusammenführen Bin trunk(dies sollte eigentlich nichts bewirken)

Der richtige Umgang mit dem Metadatenmodell wird äußerst komplex (ich weiß nicht, ob SVN dieses Szenario tatsächlich richtig handhabt, und ich bin nicht geneigt, es auszuprobieren).

Die Handhabung dieses Szenarios in Git ist äußerst einfach.

In git enthält das interne Objekt, das dieses Commit darstellt, bei jedem Commit einen Verweis auf den vorherigen Head. Wenn Sie in einem Zweig zusammenführen, enthält das Festschreiben Verweise auf den vorherigen Kopf aller zusammengeführten Zweige (Sie können mehrere Zweige gleichzeitig in git zusammenführen).

Wenn Sie also den Verlauf eines einzelnen Commits in git untersuchen, können Sie den gesamten Verlauf, den Zeitpunkt der Verzweigung und den Zeitpunkt der Zusammenführung sowie den Verlauf beider Verzweigungen zwischen der Verzweigung und der Zusammenführung anzeigen.

Wenn Sie also in einem Zweig zusammenführen, der teilweise zusammengeführt wurde, können Sie ganz einfach feststellen, was bereits zusammengeführt wurde und was nicht.

Ich habe keine Erfahrung mit Mercurial, aber ich vermute, dass seine internen Abläufe git ähnlich sind.

Grundsätzlich war es für SVN ein Designziel, die Verzweigung billig zu machen. Aber in git war es ein gestalterisches Ziel, das Zusammenführen billig zu machen.

Das letzte Mal, als ich SVN verwendet habe, war es nicht in der Lage, Zusammenführungen zu verarbeiten, bei denen eine Datei in einem Zweig umbenannt und in einem anderen geändert wurde.

Pete
quelle
1

Ich habe einiges an SVN-Zusammenführung gemacht - einschließlich langjähriger Entwicklungs- und Veröffentlichungszweige. Im Großen und Ganzen habe ich überlebt. Das Zusammenführen ist immer schwierig, aber mit DCVS ist der Nachteil nicht so schlimm - alles ist lokal, aktualisieren Sie einfach auf eine bekannte gute Revision und fahren Sie fort. Während bei SVN auf der Serverseite viel passiert ist, war die Wiederherstellung hässlich - normalerweise musste die lokale Kopie gelöscht und dann ein neuer sauberer Zweig ausgecheckt werden, um es erneut zu versuchen. War in meinem Fall nicht schlecht - eine Gigabit-Verbindung zur SVN-Box hilft. Wir hatten jedoch einige Vertragspartner, die große Probleme damit hatten, da sie langsame Verbindungen hatten, sodass alles ewig dauerte, einschließlich Zusammenlegungen.

Wyatt Barnett
quelle
Extrapoliert man die Sache mit der langsamen Verbindung, führt die Arbeit von einem externen Remote-Server aus zu miesen Verbindungsfehlern, wenn große Aktualisierungen vorgenommen werden.
Jxramos
-1

Ja, das mache ich auch. Derzeit habe ich 12 VMs für verschiedene Versionen (Zweige) des Projekts, an dem ich arbeite. Wenn ich einen Fehler in einer älteren Version beheben muss, behebe ich den Fehler und füge diese in den Zweigen für neuere Versionen zusammen. Aber das ist jetzt die Wiedervereinigung einer ganzen Branche, worüber ich hier spreche.

Hier liegt eines der sehr schönen Dinge an git. Es ist kein Erbe von DVCS, es ist nur etwas, was GIT auszeichnet. Sie können bestimmte Revisionen aus einem Zweig in einem anderen Zweig zusammenführen. Im Grunde genommen nimmt es nur das Diff und wendet es auf den anderen Zweig an, führt aber das Tracking durch und ist viel automatischer.

Wenn Sie also Zweig 2.0 und Zweig 3.0 haben und einen Fehler in 2.0 entdecken, können Sie ihn in 2.0 beheben und die Revisionen, die ihn auflösen, übernehmen und nur diese Revisionen in den 3.0-Zweig zusammenführen. Ich glaube nicht, dass SVN dazu eine andere Möglichkeit hat, als die Unterschiede für jede Revision manuell zu nehmen und anzuwenden

Natürlich scheint der automatische Zusammenführungsalgorithmus auch viel reibungsloser zu funktionieren und Git wurde von Grund auf auf dem Modell "Make a Branch for all the Things" erstellt, sodass das Verzweigen einfach und reibungslos vonstatten geht. Es scheint nur natürlich, sich oft mit dem Gewicht der Äste zu verzweigen

Earlz
quelle
Außerdem würde ich mir vorstellen, dass Mercurial eine ähnliche Funktionalität hat
Earlz
2
Tatsächlich können Sie in SVN genau dasselbe tun. Das mache ich die ganze Zeit. Mit dem Befehl SVN Merge können Sie eine Revision (oder einen Revisionsbereich) aus einem anderen Zweig abrufen und auf Ihre Arbeitskopie anwenden. Anschließend können Sie sie festschreiben.
Mason Wheeler
2
@MasonWheeler Denken Sie daran, dass ein Großteil der Anti-SVN-Stimmung auf Versionen vor 1.5 gerichtet war (als SVN Merge Tracking bekam). Und natürlich ist vieles nur sinnloser Fanboyismus ...
yannis
3
@MasonWheeler Siehe auch stackoverflow.com/a/4215199/69742 Dieser Beitrag läuft auf DVCS hinaus und verfolgt Änderungssätze, nicht Versionen . Änderungssätze sind von Natur aus einfach zu nehmen und zusammenzuführen ... Versionen sind nicht so
wichtig,
@ MasonWheeler oh und dieses: stackoverflow.com/questions/2471606/…
Earlz