Visual Studio versteckt ja so einige Perlen, die man erst nach und nach entdeckt. Eines dieser mitunter wertvollen – aber auch reichlich unbekannten Features - ist das “Cloaking”. Wie geht das, was ist darunter zu verstehen, wofür ist es gut?
Wie geht’s?
Man kann im Visual Studio – unter Verwendung von Team Foundation Server als Quellcodeverwaltungssystem –. beliebige Ordner und Branches im Source Control Explorer über das Kontextmenü “Cloaken”. Einfach Ordner anwählen, rechte Maustaste, Cloak. Die Inhalte der Folder werden dann im SourceControl Explorer ausgegraut dargestellt.
Was bewirkt das?
Das hat zu Folge, dass die “gecloakten” Inhalte nicht mehr vom Team Foundation Server nachgeladen werden – auch wenn zum Beispiel auf den übergeordneten Ordner ein “Get Latest” ausgeführt wird.
Wer braucht das?
Man stelle sich die Situation vor, dass man als Mitglied eines Entwicklungsteams bestimmte Bereiche der Quellcodeverwaltung schlicht und ergreifend nicht benötigt. Zum Beispiel, weil darin Quellcode für Komponenten entwickelt wird, mit denen man nie in Berührung kommt, und deren Schnittstellen einem auch herzlich egal sein können. Oder Branches, auf denen man eben gerade nicht arbeitet. Oder es liegen dort zwar Dateien, diese sind aber nicht für das Produkt selbst, sondern für die Herstellung der Binaries relevant – zum Beispiel Buildskripte. Dann ist genau der richtige Zeitpunkt um zu “Cloaken”.
Welchen Vorteil bringt es?
Das Cloaken bringt folgenden Vorteile mit sich:
1. Zeitersparnis – beim Ausführen des “Get Latest” Befehls werden gecloakte Unterordner nicht mit vom Server geladen. Unterm Strich geht’s also schneller, bis man die neueste Version der benötigten Files auf seiner lokalen Platte hat.
2. Bandbreitenersparnis. Aus genau dem gleichen Grund. Aus eigener Erfahrung kann ich berichten, dass Bandbreite in vielen Firmen noch ein wesentlich limitierender Faktor ist, als man im Jahr 2010 erwarten würde. Gut also, wenn man hier auf einfache Weise was sparen kann.
3. Plattenplatzersparnis – es werden weniger Files geladen. Man kann also, wenn es sinnvoll ist, gewisse gemappte Folder einfach nie getten – nicht mal einmalig. Bei riesigen Quellcodebeständen spart man sich so haufenweise Plattenplatz. Natürlich geht das nur dann, wenn man den entsprechenden Quellcode nicht doch lokal benötigt…
Gibt’s auch Nachteile?
Ja. Größter Nachteil ist, dass man genau wissen muss, was man tut. Es ist zwar einfach zu bedienen, aber man muss sich bewusst sein, dass die gecloakten Files zwar noch physikalisch auf der Platte liegen (wenn sie überhaupt schon da waren) – d.h. sie können auch referenziert werden (bspw Dlls) – aber die neueste Version eben nicht mehr automatisch vom Server geladen wird (was ja auch Sinn und Zweck ist). Wenn man also mal “vergisst”, dass man Cloaking verwendet hat, läuft man Gefahr Inkonsistenzen zu produzieren. Also: Mit Bedacht wählen was gecloakt wird – natürlich kann man es jederzeit wieder rückgängig machen.
Wen betrifft meine Cloaking-Einstellung eigentlich?
Sehr gute Frage, die immer wieder gestellt wird und bereits mit der Überschrift dieses Posts beantwortet wird: “Cloaking is a private thing” – man trifft diese Einstellung also immer nur für sich alleine und immer nur für jeweils genau einen Workspace zur gleichen Zeit. Das ist eigentlich auch sehr logisch. Den Ordner BuildProcessTemplates beispielsweise kann so ziemlich jeder im Team gefahrlos cloaken, bis auf diejenigen, die tatächlich daran arbeiten – also eben z.B. der Buildmanager. Eine Entscheidung auf Teamebene was geclaokt wird und was nicht wäre also ziemlich sinnlos.
Das gleiche gilt für Workspaces: Die Einstellungen für Cloaking kann für den Laptop zuhause grundlegend anders sein, als die Einstellung für den Arbeitsplatzrechner im Büro.
Keine Kommentare:
Kommentar veröffentlichen