Tuesday 09 January, 2007 (.Net | Team System)
Download the sample code.
I have tried different methods to move work items from one Team Foundation Server to another. The easiest method is doing it with Excel, but the problem is that I also want to keep all the work item history which Excel cannot do.
I found that the Revision property of each work item contains an array of complete copies of the work item as it appears at each revision. So iterating over each revision in order allows us to recreate each version that was saved! By setting the system time to the time of the original revision we can recreate a work item including all its changes, provided that we execute the code on our server so that the date changes are reflected when the work items are saved. An added bonus of iterating over each revision and saving them is that all the state changes are legal so we don't need to figure out how to get our work item to it's final state if we have complicated state transition rules.
If we execute our updates as a different user than the one that made the changes originally then each history entry will be tagged as "Edited by XXX on behalf of YYY". Unfortunately it appears that project reports are not updated with the historic data, all the new work items will be added to the reports the day that you import them.
The following code illustrated how I have copied almost all of the basic data from work items using revisions (unfortunately indentation was lost when I copy/pasted the code):
foreach (Revision r in wi.Revisions)
{
foreach(Field f in r.Fields)
{
if(f.ReferenceName == CoreFieldReferenceNames.ChangedDate)
{
System.Diagnostics.Debug.WriteLine(f.Name + " : "+ f.Value);
//Copy revision date
System.DateTime revDateTime = (System.DateTime)f.Value;
revSysTime.wDay = Convert.ToUInt16(revDateTime.Day);
revSysTime.wHour = Convert.ToUInt16(revDateTime.Hour);
revSysTime.wMilliseconds = Convert.ToUInt16(revDateTime.Millisecond)
revSysTime.wMinute = Convert.ToUInt16(revDateTime.Minute);
revSysTime.wMonth = Convert.ToUInt16(revDateTime.Month);
revSysTime.wSecond = Convert.ToUInt16(revDateTime.Second);
revSysTime.wYear = Convert.ToUInt16(revDateTime.Year);
}
if(f.ReferenceName != CoreFieldReferenceNames.History
&& f.ReferenceName != CoreFieldReferenceNames.WorkItemType
&& f.ReferenceName != CoreFieldReferenceNames.TeamProject
&& f.ReferenceName != CoreFieldReferenceNames.Id
&& f.ReferenceName != CoreFieldReferenceNames.IterationId
&& f.ReferenceName != CoreFieldReferenceNames.IterationPath
&& f.ReferenceName != CoreFieldReferenceNames.AreaId
&& f.ReferenceName != CoreFieldReferenceNames.AreaPath
&& f.ReferenceName != CoreFieldReferenceNames.CreatedBy
)
{
if(!f.IsComputed && f.IsValid)
{
destItem.Fields[f.Name].Value = f.Value;
}
}
}
System.Collections.ArrayList arrl = destItem.Validate();
if(arrl.Count > 0)
{
//Handle validation errors
}
else
{
GetSystemTime(ref currentSysTime);
SysTimeNeedsReset = true;
if(SetSystemTime(ref revSysTime) == 0)
{
throw new ApplicationException("SystemTime was not set!");
}
destItem.Save();
if(SetSystemTime(ref currentSysTime) == 0)
{
throw new ApplicationException("SystemTime was not reset!");
}
SysTimeNeedsReset = false;
}
}
You can download the code to the minimal WinForms app that I have created for copying work items here. The code is provided as-is with no guarantees or support...
Things that are not handled at all are: user mappings if the source and destination server have different users, area and iterations, links and attachments. There may be more things that are missing or don't work that haven't affected my setup.
Tuesday 09 January, 2007 (Team System | Tips)
I have had several discussions with people I work with about where to put your documents when using Team Foundation Server. Obviously there are several places to put documentation depending on what sort of document it is. There are at least three places that make sense to me:
- In the SharePoint Portal
- In the Version Control repository
- As attachments on Work Items
Each of these places has their advantages and disadvantages. I have found two interesting blog posts on one by Jason Barile and one by Jeff Atwood. For me I only use Work Item attachments for documents that have no project-historic value and only cover a single work item. Screen shots for bugs is a classic example. Anything that is scoped to more than a single work item or might be of value for new project members as background material or details of why the system has been built the way it is must be stored somewhere more visible.
The Version Control repository is great for code, but for me I really don't want to see documentation in there for two reasons. All project members might not have Team Explorer installed. That means that anything that is placed under source control is effectively hidden to project members who don't work in Visual Studio. In addition the documents might not be fully visible to project members who do use Visual Studio since generally we map up our Solutions and projects and get the latest version through the IDE integration in the Solution Explorer not by using the Source Control Explorer. So if someone creates a new folder in Source Control that is not part of one of the projects that I am working on then I generally won't see it straight away. The SharePoint Portal has two advantages visibility and accessibility. All the documents are clearly visible in one place (Documents and Lists) and in addition we are not restricted to documents we can also use lists and WebParts to display additional data like reports and external links to help project members understand whats going on in addition to just getting hold of the right documents. Users who want to find information aren't required to have Visual Studio installed and configured they only need a browser to get hold of the documents.
- Use the SharePoint Portal for info that needs high visibility.
- Use the Version Control repository for code.
- Use Work Item attachments for documents that only relate to a single work item.