|
|
Der Team Foundation Server ist die zentrale Plattform für alle Artefakte von Software-Entwicklungsprojekten. Anforderungen, Code, Testfälle, Entwurfsdokumente – alles lässt sich versioniert und für die Zusammenarbeit in Teams zentral ablegen. Doch wie hängen diese verschiedenen Artefakte zusammen und wie kann das im Team Foundation Server abgebildet werden?
Vor allem frühere Nutzer von Visual SourceSafe arbeiten im Team Foundation Server immernoch mit exklusiven Checkouts. Das bedeutet, dass ständig die für eine dringende Änderung zu bearbeitende Datei von einem anderen Benutzer blockiert ist. Viele Nutzer haben mit dem Merge von konkurrierend ausgecheckten Dateien schlechte Erfahrungen gemacht. Teilweise mag das am Vergleichs- und Mergewerkzeug liegen, welches der Team Explorer mitbringt. Was viele nicht wissen, Sie können diese Werkzeuge sehr einfach ersetzen und Ihren eigenen Vorlieben entsprechend anpassen. Im folgenden sollen die Alternativen aufgelistet werden.
Folder-Compare unter Verwendung von Microsoft Excel.
Die Team Foundation Version Control bietet die Möglichkeit, Source Code zu branchen. Damit kann man z.B. Hotfixes für ausgelieferte Versionen der Applikation auf dem sogenannten Wartungs-Branch entwickeln, während bereits neue Funktionalitäten auf dem Entwicklungs-Branch eingebaut werden. Mit Hilfe der Merge-Operation können Änderungen an einem der Branches zu einem anderen übertragen werden. Dabei gibt es die Option alle Änderungen bis zu einer bestimmten Revision des Branches oder aber nur ausgewählte Änderungen zu übernehmen. Dabei kommt es evtl. zu unerwarteten Effekten, auf die wir hinweisen möchten.
Die früh angekündigte neue Version (Visual Studio Team System 2008 Power Tools - October Release) der Power Tools ist zum Download verfügbar. Für Installation und Anwendung sind einige Dinge zu beachten…
Über den Befehl "Get Specific Version…" kann man im Source Control Explorer eine alte Version einer Datei oder eines Verzeichnisses wiederherstellen.
Wählt man ein altes Changeset oder Datum aus, wird die lokale Datei mit der alten Version überschrieben (so denn das Häkchen zum Überschreiben im Dialog gesetzt ist). Das ist im Source Control Explorer anhand der Spalte "Latest" erkennbar.
Doch wie war doch jetzt gleich die aktuelle lokale Version der Datei? Um das herauszufinden, muss man einen Blick in die Eigenschaften der Datei werfen. Dort sind aktuelle Server und lokale Version aufgelistet.
Gerade für frühere Visual-SourceSafe-Benutzer ist das Labeling im TFS evtl. missverständlich. War doch ein Label im Visual-SourceSafe ein “benannter Zeitpunkt”, der auch in der Dateihistorie angezeigt wurde. Ganz anders und mächtiger im TFS. Doch mit großer Macht kommt große Verantwortung. Und für alle Verantwortlichen soll dieser Blogeintrag das Labeling im TFS verständlicher machen.
Die Versionsverwaltung (auch Quellcodeverwaltung genannt) des TFS bietet die Möglichkeit, Pending-Changes zentral zu verfolgen. Das bedeutet, dass alle Check-Outs oder Locks eines Benutzers zentral verfügbar sind - wohlgemerkt nicht die lokalen Änderungen, die noch nicht eingecheckt worden sind.
Die Möglichkeiten, diese Funktionalität des TFS für die Steuerung eines Projekts zu nutzen, sind dagegen eingeschränkt. Nicht nur der Überblick üder die Pending-Changes, sondern z.B. auch über die gesetzten Berechtigungen der Verzeichnisse und Dateien in der Versionsverwaltung sind nur schwer zu gewinnen.
Dieser Beitrag soll aufzeigen, wie die Versionsverwaltung durch den Einsatz von wenigen einfachen Berichten besser in den Griff zu bekommen ist…
| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||