SVN External Alternative in Team Foundation Server 2012

Question

Momentan verwenden wir SVN für unsere Quellcodeverwaltung. Aufgrund der zusätzlichen Funktionen und Integration in die Entwicklungsumgebung möchten wir gerne zu TFS 2012 migrieren.

Wir haben eine Menge von Portalen, die in asp.net gebaut werden. In unserem Portal verwenden wir viele Standardkomponenten. Derzeit verwenden alle Portale dieselbe Codebasis. Dies bedeutet, dass, wann immer wir etwas in der geteilten Codebasis ändern, es (wenn ein Portal veröffentlicht wird) automatisch verteilt wird. Wir sind sehr an diese Arbeitsweise gewöhnt und wir wissen, dass das Risiko besteht, dass Code in anderen Portalen gebrochen wird. Publishing-Änderungen in allen anderen Portalen würden jedoch viel Zeit kosten. Um dies zu tun, verwenden wir Externals in SVN.

Ich würde wirklich gerne diese Funktionalität aufrecht erhalten. Meine Frage ist also, gibt es eine Möglichkeit, ein externes ähnliches System in SVN zu erstellen oder gibt es einen wirklich guten Weg, der genauso effizient arbeitet, um diese Funktionalität zu ersetzen.

Answer 1

Es gibt ein paar Vorschläge in der Visual Studio Team Foundation Server Branching and Merging Guide.

Wenn Sie das "Everything" -Paket herunterladen und in "All Guides" nachsehen, lesen Sie den "Advanced Version Control Guide".

Seiten 5-19 (Version 2.1) cover Verwalten von freigegebenen Ressourcen, da ist eine Menge da und das Zusammenfassen für Stack Overflow wird dem Ranger wahrscheinlich Unrecht tun, also werde ich Sie einfach dorthin verweisen.

Answer 2

Fazit: Nein TFS hat kein Äquivalent zu "svn: externals".

Code-Sharing ist schlecht und führt zu Code-Duplikation und nicht Code-Wiederverwendung. Sei stattdessen auf kompilierten Code angewiesen.

Sie sollten nur von der "Ausgabe" der gemeinsam genutzten Bibliothek und nicht von den Quelldateien abhängig sein. Was Szenarien betrifft, kann ich mir keine Szenarien vorstellen, in denen es sinnvoll ist, Quelldateien zwischen Produkten/Lösungen zu teilen.

Der Grund dafür ist, dass Dinge sehr schnell unhandlich werden können. Was passiert, wenn Sie als eine abhängige in eine gemeinsam genutzte Bibliothek verschieben, die alle auf den gleichen Code geändert werden und sie sich abwechselnd gegenseitig unterbrechen. Der einzige Weg dahin ist, den gemeinsamen Code in die anderen Projekte zu verzweigen, was nun eine Komplexität und Integration mit sich bringt, die auf lange Sicht niemals behandelt werden und Sie werden mit drei oder mehr Versionen derselben Code-Basis enden Zeit.

Was Sie tun sollten, ist eine einzelne Kernkomponente, die geändert und erstellt wird, um die Ausgabe zu erzeugen. Diese Ausgabe kann dann bei Bedarf in die anderen Projekte gezogen werden, die von diesen Änderungen abhängig sind oder nicht. Dies führt zu weniger Brüchen, einer besseren Architektur und weniger technischen Schulden.

Sie können NuGet sogar in die Gleichung einbeziehen, indem Sie entweder einen hauseigenen Server verwenden, um Ihre gemeinsame Komponente zu veröffentlichen, und jeden der Benutzer benachrichtigen, wenn eine neue Version verfügbar ist.