To demonstrate why labels such as "Sprint 5", "M1", "Beta2", and "Release Candidate 0" are impractical consider the following TFS repository, project "MarkI" with two folders representing two separate applications: the Inventory App and the Mapping App:
The team working on the Inventory App has reached "Sprint 5" so their build engineer right clicks on the Inventory App folder and selects Apply Label from the Advanced sub-menu:
The build engineer for the Inventory App creates the label, "Sprint 5".
A few weeks later the Mapping App also reaches milestone "Sprint 5" so their build engineer attempts to apply the label "Sprint 5" to folder Mapping App resulting in the following error message:
The label "Sprint 5" has to be unique to a TFS project (the collection root, e.g. MarkI) and not a folder such as Inventory App or Mapping App. One firm I have worked with checked in their SVN source tree into a TFS project that include ten applications so requiring labels to be per-TFS-project unique rather than per-folder unique means that labels such as "Sprint 5", "M1", "Beta2", and "Release Candidate 0" are useless.
The correct way to label is to include the folder name and enough information to make the label unique. A more logical label would be: Inventory App V3 Sprint 5. The previous label is project unique and will not clash with labels prefixed with Mapping App. The previous label would also not conflict with versions V4 and V5 of the Inventory App.
No comments :
Post a Comment