Ich erinnere mich an zwei Ereignisse in der SVN Geschichte: TortoiseSVN wurde benutzbar und VisualSVN wurde benutzbar.
Das Ergebnis des ersten: "Wir werden nie SVN mit Befehlszeile verwenden wollen". Das Ergebnis des zweiten: "Wir werden nie SVN und MSVS ohne VisualSVN verwenden"
Bitte verstehen Sie das richtig - wir verwenden die SVN-Befehlszeile, wenn wir etwas brauchen, das mit Tortoise nicht erreicht werden kann, und wir verwenden Tortoise, wenn etwas, das wir brauchen, nicht von MSVS verfügbar ist. Aber ansonsten (99,9% der Zeit) ist alles, was Sie brauchen, direkt in der IDE verfügbar.
Jetzt verstehe ich und mag die Vorteile der verteilten Quellcodeverwaltung, aber es gibt einfach keine Möglichkeit, Dateien in der IDE umbenennen zu lassen und manuell hg umzubenennen, um den Verlauf nicht zu verlieren ("delete + create new" "statt" Umbenennen "= keine Historie). Ich denke auch nicht, dass eine Zurückweisung oder eine Dateirücknahme eine Aktion ist, die nicht direkt mit einer Datei ausgeführt werden kann, die im Lösungsexplorer ausgewählt oder zur Bearbeitung geöffnet wurde. Mit VisualSVN funktioniert das alles und vieles mehr!
Die konzeptionellen Vorteile von DSCM sind großartig, aber sie sind nicht gut, wenn einfache, täglich genutzte Funktionen nicht über die IDE verfügbar sind!
Die Frage: Gibt es eine verteilte Quellcodeverwaltung mit Plug-in, die so reibungslos in MSVS integriert ist wie VisualSVN? Git Extensions und VisualHg sind im Moment nirgends so nahe bei VisualSVN Das Team verweigert die Erstellung von VisualGit mit:
P.S. Ein Muss von IDE:
Nicht viel ist es?
UPDATE:
1) Getestet HgSccPackage gestern. Es hat sicher mehr benötigte Funktionen direkt von IDE, und sie respektieren den aktuellen Kontext, z. B. ausgewählte / offene Datei usw. Leider ist der Lösungsbaumstatus derzeit fehlerhaft und unterstützt den Ordnerstatus nicht.
2 Git Source Control Provider erwähnt in einer Antwort gleich als VisualHG fehlen mindestens 2 Dinge:
3) Charles Bailey wies darauf hin, dass git sowieso umbenennt . Ja, tut es. Keine Notwendigkeit für irgendeine IDE-Unterstützung hier (nicht sicher über mercurial). So fehlt der MSVS-Unterstützung nur ein guter Kontext, Ein-Klick-Aktionen und eine korrekte Unterstützung des Baumstatus (gut, es gibt auch eine gelbe Linie, aber sagen wir, es ist sehr nett zu haben, aber im Moment kein Muss).
Meine Antwort: Nein.
2 Wochen, in denen verschiedene Tools und Plug-Ins erforscht und getestet wurden. Resume: Zum Zeitpunkt des Schreibens gibt es nicht eine einzige freie verteilte Quellcodeverwaltung, die so einfach in MSVS integriert ist wie SVN mit VisualSVN.
SVN ist nicht verteilt, und VisualSVN ist nicht frei, deshalb war ich auf der Suche nach etwas anderem.
2 Wochen Forschung ist für mich keine kleine Untersuchung, das ist der einzige Grund, warum ich diese Antwort poste - hoffe, dass sie für andere da draußen "am Rande der Veränderung" nützlich sein wird.
Achte auch darauf, dass ich alle meine Fragen und Antworten darauf beachte - wann immer mir jemand beweisen sollte, dass es falsche Werkzeuge gibt, werde ich diese Antwort entfernen und eine bessere als "die Antwort" markieren ".
P.S. Die Zukunft liegt in verteilten Versionskontrollsystemen. Wenn Sie heute einen auswählen müssen, wählen Sie einfach einen aus. Du wirst sowieso nicht viel verpassen. Heute würde ich wahrscheinlich nach Git gehen. Aber das ist wirklich nur ich.
Ich habe festgestellt, VS-Integration für Git sinnlos. Die einzige Zeit, die Sie benötigen, um mit Git zu interagieren, ist, wann Sie das Remote-Repository bereitstellen, festschreiben und an dieses übertragen möchten.
Dies ist getan, wenn Sie mit der Programmierung fertig sind und der Code kompiliert und Tests usw. besteht ... Es ist an dieser Stelle ich benutze Git über die Befehlszeile oder TortiseGit.
Ich mag, wie der Git-Workflow funktioniert, erlaubt mir zu arbeiten, ohne zu wissen, dass es eine Quellcodeverwaltung gibt, und kommt nur ins Spiel, wenn ich meine Arbeit teilen muss oder an einem sicheren Punkt begehen muss.
Wir verwenden Git und TortiseGit seit ein paar Monaten in meinem Unternehmen, und selbst die VisualSVN-Nutzer verpassen es nicht.
Über die Visual Studio-Integration für GitExtensions. "Wir" haben die gewünschte Integration nicht hinzugefügt, weil es nicht gut mit dem Git-Workflow funktioniert. Wenn es keine Dateisperr- oder Umbenennungsprobleme gibt, können Sie die Quellcodeverwaltung einfach vergessen, bis Sie die Änderungen übernommen haben.
Nachdem das gesagt wurde: Es gibt ein Plugin für Visual Studio, das das tut, was Sie verlangen. Sie können es hier finden: Ссылка Dieses Plugin für Visual Studio fügt ein Versionskontrollanbieter für Git- und Git-Erweiterungen in Visual Studio.
Ich bin mir über TortoiseGit nicht sicher, aber als GitExtensions gibt es keine Pläne, einen Quellcode-Steuerungsanbieter für Visual Studio hinzuzufügen. Dies ist kein technisches oder zeitliches Problem, es ist bereits in der "scc" Branche aufgebaut. Die Workflows, die Visual Studio verwendet, unterscheiden sich nur von denen, die ein typischer DVCS verwendet. Wenn Sie einen Source Control Provider sehr wichtig finden, ist es vielleicht besser, bei SVN zu bleiben, da dies für Ihren Workflow besser geeignet ist.
Uh, haben Sie sich Team Foundation Server angeschaut, das MS-gestützte Quellcodeverwaltungstool + Projektmanagementlösung? Die 2K10-Version ist ziemlich solide.
Das klingt nach einem Umdrehen der Dinge, aber so mache ich es. Ich benutze C ++. Ich code in Eclipse und ich kompiliere und debugge in VS. Eclipse hat ein Plugin für Git, und wenn ich das nicht irre, dann tut es mehr oder weniger die Dinge, die man erwartet. (zugegebenermaßen habe ich nicht alle sehr gut gemacht, ich habe auch nie Anmerkungen verwendet) Wenn es nicht so ist, ist es Open Source, also können Sie es besser machen!
Sie müssen für zwei verschiedene Projekte zwei Projekte erstellen und die Includes usw. verfolgen, aber als zusätzlichen Vorteil haben Sie nicht nur eine Git-Integration, sondern auch eine bessere Gliederung und Syntaxhervorhebung, Ein-Klick-Code-Navigation und Zurück-Schaltfläche usw. Es gibt ein paar Aspekte von VS, die besser sind, aber sie sind kleinere Probleme und ich bin mir sicher, dass eclipse cdt im Laufe der Zeit verbessert wird.
Tags und Links git visual-studio svn mercurial open-source