Work Item Tracking Policies

Below is a list of policies for the various items that are synchronized by WIT sessions. The policies below each have a reaction associated with them that determines the action taken by the toolkit to resolve conflicts. Some of the policies also have a notion of a "master" system. In these cases, either TFS or the other system is chosen as the winner when decisions are made as to how items should be synchronized.

Missing User

The reaction for the MissingUser policy specifies how work items with a username that does not exist in TFS or the other system should be handled. The options for the reaction are defined in the table below.

throw The throw reaction will cause the Toolkit to throw an event if a username is encountered that is not in the target system.
default The default reaction will cause the Toolkit to default to a specified user account if a username is encountered that is not in the target system. Using the Default policy for the reaction requires a defaultUser value to be supplied.

Field Conflict

The reaction for the FieldConflict policy specifies how work items with conflicting fields should be handled. Fields conflicts occur when a field in two synchronized work items is changed in both systems.

throw The throw reaction will cause the Toolkit to throw an event if a field conflict is encountered.
master The master reaction will cause the Toolkit to default to the field of the system designated as the master. Using the Master policy for the reaction requires a master value to be supplied.


The table below defines the values that can be supplied for the master value of the Master reaction.
default The default system is chosen to be the master. This is the default chosen by the tool author.
tfs TFS is chosen as the master system. Any field conflict will result in the value from TFS being applied to both systems in synchronization.
other The other system (not TFS) is chosed as the master system. Any field conflict will result in the value from the other system being applied to both systems in synchronization.

Attachments Conflict

The reaction for the AttachmentsConflict policy specifies how work items with conflicting attachments should be handled. Attachments can conflict whenever attachments are found on a work item in synchronization. Because TFS does not record history for attachments, it is difficult to determine what has changed when two work items are found to have different attachments.

One scenario is if the two synced work items have attachments with different names. Without performing an expensive comparison of the contents of the attachments, a rename cannot be distinguished from a delete and add. Another scenario is if an attachment is changed in one system, but the name and size remains the same (i.e. one character changed in the attachment).

throw The throw reaction will cause the Toolkit to throw an event if an attachment conflict is encountered.
union The union reaction will cause the Toolkit to create a union of the file attachments on the synchronized work items, and save the union to both work items.
master The master reaction will cause the Toolkit to default to the attachments of the system designated as the master. Using the Master policy for the reaction requires a master value to be supplied. The options for the master value are the same as those for the FieldConflict policy.


In addition to using the name to determine if there are attachments conflicts, other criteria may be used.
createTime This is the time that the attachment was created.
lastWriteTime This is the time that the attachment was last written.
all All of the criteria are used to determine how the attachment conflict should be resolved.

Links Conflict

The reaction for the LinksConflict policy specifies how work items with conflicting links should be handled. Links conflicts are similar to attachment conflicts in that they have no history to determine the changes between synchronized work items.

throw The throw reaction will cause the Toolkit to throw an event if a links conflict is encountered.
union The union reaction will cause the Toolkit to create a union of the links on the synchronized work items, and save the union to both work items.
master The master reaction will cause the Toolkit to default to the attachments of the system designated as the master. Using the Master policy for the reaction requires a master value to be supplied. The options for the master value are the same as those for the FieldConflict policy.

Missing Area

The reaction for the MissingArea policy specifies how work items with a missing area path should be handled.

throw The throw reaction will cause the Toolkit to throw an event if an area path is missing.
create The create reaction will create the missing area path in the target system.
default The default reaction will use a default area path for the target system.

Missing Iteration

The reaction for the MissingIteration policy specifies how work items with a missing iteration path should be handled.

throw The throw reaction will cause the Toolkit to throw an event if an iteration path is missing.
create The create reaction will create the missing iteration path in the target system.
default The default reaction will use a default iteration path for the target system.


Last edited Jun 29, 2007 at 3:52 PM by mmitrik, version 1

Comments

No comments yet.