TortoiseSVN Working Copy / Revision commiting ist nicht richtig

Question

Ich habe eine VS 2008-Projekt unter TortoiseSVN Quellcodeverwaltung. Ich bin die einzige Person, die es derzeit verwendet wird.

Ich habe versucht, meine letzte Änderungen zu übernehmen, wenn ich die Nachricht empfangen „Datei abc veraltet ist - bitte aktualisieren“. Wenn ich versuche, das Projekt zu aktualisieren, erhalte ich eine ganze Reihe von Dateikonflikten (binär und Text). Da ich bin zuversichtlich, meine Arbeitskopie enthält die korrekte Version der Dateien, versuche ich, durch die Auswahl von „Mine“, wie die richtige Version, die Konflikte zu lösen. Ich habe versucht, Markierung auch nur jede Datei Konflikt als aufgelöst. Ich bin dann in der Lage zu begehen.

Doch nach dieser mein VS 2008 Projekt zu kompilieren verweigert, und Hunderte von Fehlern gibt (so viele Fehler, dass VS 2008 berichtet, dass es zu viele Fehler zu zeigen!). Etwas über TortoiseSVN Konfliktlösung völlig vermasselt das Projekt, und es ablehnt, zu bauen.

Jede Art, wie ich TortoiseSVN zwingen, kann nur meine Arbeitskopie in das Repository als die neueste Revision zu speichern, ohne Konflikte zu überprüfen?

Answer 1

Ich hoffe, dass Sie eine Sicherungskopie Ihrer Arbeitskopie gemacht haben vor dem Update, weil es sonst sehr wahrscheinlich ist, dass die Konflikte zu einem riesigen Haufen von >>>>>> theirs geführt haben und <<<<<<< mine Kommentare in Ihren Quelldateien.

Während ich verstehe nicht, wie die Konflikte in erster Linie passieren könnte (da Sie der einzige in das Repository zu begehen sind), gibt es eine mögliche Lösung.

Bewegen Sie die aktuellen, „arbeiten“ Arbeitskopie an einem sicheren Ort. Überprüfen Sie das Projekt ganz frisch aus. Kopieren Sie Ihre Quelldateien über das neue Arbeitskopie und dann verpflichten, die sich daraus ergebenden Veränderungen.

Wenn Ihr Quellbaum aus mehreren Verzeichnissen besteht, könnte es sehr mühsam sein einzeln jedes Verzeichnis zu kopieren. Um dies zu überwinden Sie können Ihre sichere „arbeiten“ Arbeitskopie TortoiseSVN exportieren -> Alle exportieren. Dies erzeugt ein Verzeichnis ohne alle .svn Dateien und Verzeichnisse. Anschließend können Sie das exportierte Verzeichnis über die neue Arbeitskopie kopieren.

Answer 2

Ich habe festgestellt, dass Visual Studio Projektdateien automatisierte Zusammenführen Probleme ziemlich anfällig sind. Das Problem besteht darin, dass das Format der Dateien, so repetitiv ist, hat das Merge Dienstprogramm eine sehr schwierige Zeit zu bestimmen, ob eine Änderung eine Addition oder eine Modifikation ist. Auch scheinen einige Aktionen Visual Studio neu zu ordnen entires in der Projektdatei zu verursachen. Wiederum sind diese Änderungen relativ schwierig für das Merge Dienstprogramm richtig zu handhaben.

Ich setze auf eine von zwei Optionen, dies zu beheben. Erstens könnten Sie die Projektdatei in Notepad öffnen und von Hand beheben. Sie sind nicht so komplex und Sie können in der Regel nur dem Muster folgen und sicher nichts machen fehl am Platz ist.

Der zweite Ansatz wäre es, die Projektdatei zurückkehrt und dann hinzufügen und Dateien entfernen und andere Änderungen vornehmen, wie in Visual Studio benötigt.

Wenn Commits gemacht werden früh und oft ist keine dieser Aufgaben zu komplex. Wenn Bomben auf dem Repository gelöscht werden, na ja, ist dies einer der vielen Gründe, warum früh und oft zu begehen ist eine gute Idee. =)

Answer 3

Visual Studio und TortoiseSVN nicht spielen schön zusammen. Eine Sache, die ich bemerkt habe ist, dass man nicht erfolgreich etwas Version in einem Build-Verzeichnis, weil VS denkt, dass es „besitzt“ die Build-Verzeichnisse und ist wahrscheinlich, dass Ihr .svn Ordner löschen (das ist nur für baut einen sauberen beteiligt? )

Sie könnten an einem Subversion-Client suchen, die in Visual Studio integriert. AnkhSVN in dem Sinne, aber ein guter Ausgangspunkt, dies zu erforschen wäre http: //sharpsvn.open.collab. net / . Alternativ könnten Sie die SharpSvn mit direkt von einem Pre- oder Post-Build-Task, oder vielleicht ein Makro in Visual Studio.