Mergeinfo Subversion Durcheinander nach der Zusammenführung Stamm auf den Zweig

Ich bin testing neuere Versionen von Subversion, sowohl die SVN-Kommandozeilen-client und TortoiseSVN. (Bis zu diesem Punkt habe ich mit meist Versionen, die vor der Einführung der mergeinfo Eigenschaften und die --reintegrate merge-Schalter.)

Habe ich die obligatorischen Googeln, aber entweder haben wirklich schlechte Google-fu oder was folgt, ist tatsächlich ein problem, das niemand hat erklärt und/oder gelöst gründlich. Ich finde das etwas verwirrend sein, da hier zahlreiche Berichte über die problem - kein problem bei der Suche nach diesen berichten. Ich finde auch andere Diskussionen auf der mergeinfo-prop ' s, aber nichts, was wirklich passt und erklärt/löst das, was ich erlebe.

Ich würde schätzen jede Hilfe, die Sie im ' Ing bis mein Google-fu oder das Verständnis, was geht und was zu tun ist.

Hier geht:

  1. Ich habe einen Stamm (und eine Arbeitskopie Basierend auf it)

  2. Erstelle ich eine Filiale (und eine Arbeitskopie Basierend auf it)

  3. Habe ich einige änderungen im WC des Rumpfes und verpflichten

  4. Ich einige arbeiten im te-WC der branch und commit

  5. Ich nun Zusammenführen der arbeiten in den Kofferraum, um das WC von meinem Zweig, der Beilegung von Konflikten.

So weit alles wie erwartet, aber wenn ich versuche zu verpflichten, das Ergebnis der Zusammenführung, aber ich erhalte eine Meldung, die besagt, dass die Arbeitskopie ist veraltet und muss aktualisiert werden, ersten.

Macht das keinen Sinn. Das WC war up-to-date-unmittelbar vor der Zusammenführung und Ziel der Zusammenführung war die WM. So gar nichts hätte sich verändert in den repo.

Diging tiefer es scheint, ist es der mergeinfo Eigenschaft als solche, das ist das problem.

Habe ich kein problem, Begehen die geänderten Dateien einzeln, aber nach, dass das WC immer noch schmutzig/nicht vollständig begangen, und ich kann immer noch nicht Begehen, weil das WC ist nicht up-to-date. So, es scheint, dass Subversion wurde, berühren Sie die mergeinfo sowohl im repo und im WC.

In dem Fall, dass ich mich wiederholen, für diese Untersuchung habe ich kein problem, das das update von der WM zuerst, und dann Begehen. Aber ich bin nicht sicher, ob dies immer der Fall sein wird, oder andere Varianten dieses Phänomen wird schwieriger zu lösen. Ich weiß auch nicht freuen versuchen zu "erklären" das zu den nahe gelegenen Subversion-Benutzer, die nicht haben dies als eines Ihrer "wichtigsten Werkzeuge".

Habe ich getestet und gehen für mehrere Jahre und ich denke, das problem hat sich seit der Einführung der mergeinfo-und --reintegrate-Funktionalität (1.5?) bis jetzt. Kann das so sein? Und es ist immer noch nicht in Angriff genommen?

Meine aktuellen tests wurden sowohl mit der Kommandozeilen-client (installiert von CollabNetSubversion-client-1.6.17-4.win32.exe) und TortoiseSVN (TortoiseSVN-1.6.16.21511-win32-svn-1.6.17.msi), und ich bekomme die gleiche Ergebnisse.

Ich habe mit Subversion für viele Jahre jetzt und haben Sie beschrieben mich als "power-user". Doch mit diesem Problem stehe ich mit meiner Hose runter..

Nachtrag

Hier sind die Schritte, mit denen ich das problem reproduzieren können:

  1. Erstellen Sie ein repository, in "C:\Documents und Einstellungen\johndoe\Eigene
    Dokumente\SVN\Repo"

  2. Mit den Repo-browser, erstellen Sie mit "file:///C:/Dokumente und
    Einstellungen/johndoe/Meine Dokumente/SVN/Repo/Trunk" (r1)

  3. Mit den Repo-browser, erstellen Sie mit "file:///C:/Dokumente und Einstellungen/johndoe/Meine Dokumente/SVN/Repo/Branches" (r2)

  4. Erstellen Sie eine Arbeitskopie des trunk in "C:\Documents und Einstellungen\johndoe\My Documents\SVN\WCs\Trunk" (keine neue Version)

  5. In den Kofferraum, erstellen Sie eine text-Datei test.txt, add und commit (r3)

  6. Erstellen Sie ein Zweig des Stammes in "file:///C:/Dokumente und Einstellungen/johndoe/Meine Dokumente/SVN/Repo/Branches/Branch1" (r4)

  7. Erstellen Sie eine Arbeitskopie für diesen Zweig in "C:\Documents und Einstellungen\johndoe\My Documents\SVN\WCs\Branch1" (keine neue Version)

  8. In der Arbeitskopie Basierend auf Stamm, fügen Sie eine Zeile text in test.txt und verpflichten (r5)

  9. In der Arbeitskopie Basierend auf Branch1, fügen Sie eine Zeile text in test.txt und verpflichten (r6)

  10. Zusammenführen der Stamm in den Zweig ein. Rechts klicken Sie auf "C:\Documents und
    Einstellungen\johndoe\My Documents\SVN\WCs\Branch1", Tortoise SVN Merge.
    Merge-Typ "einen Revisionsbereich Zusammenführen", URL Zusammenführen von:
    "file:///C:/Dokumente und Einstellungen/johndoe/Mein
    Dokumente/SVN/Repo/Trunk", Revisionen: Arbeiten
    Kopie: "C:\Documents und Einstellungen\johndoe\Eigene
    Dokumente\SVN\WCs\Branch1", alles, was sonst Standard. Lösen
    Konflikt-Dialog "alle später Lösen". (keine neue revision)

  11. Den Konflikt zu lösen. Der rechten Maustaste auf die Datei, Tortoise SVN, Bearbeiten
    Konflikte. In TortoiseMerge, markieren und wählen Sie "Ihrigen vor mir",
    klicken Sie auf "Markieren als "gelöst", speichern und beenden. (keine neue Version).

  12. Versuchen, einen commit der änderungen in Branch1.

In diesem Punkt habe ich eine Nachricht bekommen

Commit
C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1
Commit failed (details follow): 
Directory '/Branches/Branch1' is outof date 
You have to update your working copy first.

Dieser nicht die für mich Sinn machen: Vor dem Zusammenführen der Arbeitskopie war up-to-date. Nach, dass es keine neuen Versionen erstellt wurden (repo-KOPF ist immer noch r6), und jetzt meine Arbeitskopie ist nicht up-to-date.

Genauer zu untersuchen, scheint es wie ein Update der WC für Branch1 so früh wie zwischen den Schritten 9 und 10 macht das problem Weg. Wieder, dies macht für mich keinen Sinn:
i) In dem Dialog am Ende des update, nichts gemeldet wird als tatsächlich aktualisiert werden, und
ii) Die eine und einzige, was geändert in der Branche ist bereits engagiert.
So, in meiner Sicht ist das WC ist sowohl "clean" (keine uncommitted) und up-to-date (nichts in der repo dazu beitragen, das WC).

Das einzige, was das update tatsächlich tut, ist zu ändern Sie die BASIS der Arbeitskopie Branch1 von r4 auf r6. Ist das irgendwie von Bedeutung, aber jetzt ist mein Kopf dreht zu viel für mich, nageln Sie die details unten.

Ich würde schätzen jedes frische Gedanken zu machen, dass Sie mich sehen, was hier vor sich geht.

Nachtrag 2

Weiteren versuchen zu klären, mein denken: Die FAQ, auf die verwiesen wurde, sagt

Wenn Subversion verpflichtet sich, dem AUFTRAGGEBER nur zu, Beulen die Revisionsnummern von
die Knoten die commit berührt, nicht alle Knoten in der Arbeitskopie. Diese
bedeutet, dass in einem einzigen Arbeitsgang zu kopieren, die Dateien und Unterverzeichnisse
könnte an verschiedenen Versionen, je nachdem, Wann Sie zuletzt begangen
Sie. In bestimmten Operationen (z.B. directory-Eigenschaft
änderungen), wenn das repository eine neuere version der
Knoten, wird der commit abgelehnt werden, um Datenverlust zu verhindern.

Interpretiere ich die "Knoten" als "file:///C:/Dokumente und Einstellungen/johndoe/Meine Dokumente/SVN/Repo/Branches/Branch1" in meinem Fall. So wie ich das sehe, ist das repository nicht "eine neuere version von [die] - Knoten". Insgesamt ist der LEITER der repo ist, r6, aber die aktuelle version von node in Frage r4.

InformationsquelleAutor johanekdahl | 2011-07-20
Schreibe einen Kommentar