Applies to
ApexSQL Source Control
Summary
This article describes how a Team Foundation Server work item can be associated with a changeset prior to performing a commit operation.
Description
After linking a database to a Team Foundation Server repository each changeset that is ready to be committed can be associated with a work item in the commit message. For instance, we have modified the AddRoleMemberIfNonexistent stored procedure in a sample database. When a change is made and the Action center tab is refreshed, it will look like as follows:
By specifying a comment that starts with the ‘#’ character followed by the work item ID (for example #A2 where ‘A’ means “to associate” while 2 represents a work item ID) and a commit message, changes that are selected to be committed will be associated with the specified Team Foundation Server work item.
|
Quick tip: A specified work item, in this case #A2, does not have to be placed at the beginning of the commit message. |
A part of the commit message that holds the information about the work item to be associated with a changeset must be delimited with at least one empty space after the work item ID. As an example, the following is a work item association correctly specified:
#A23 Commit message
On other hand, if the work item association is not specified at the beginning of the commit message, it does not have to be necessarily delimited with an empty space on the left side. As an example, the following is a work item association correctly specified:
Commit message#A23 Commit message
A situation that is not allowed is that a work item association is not delimited with an empty space on the right side. For instance, the following is an example of incorrectly specified work item association:
#A23Commit message
Besides associating a work item ID with a changeset using the ‘A’ character before the actual work item ID, it can be resolved using the ‘R’ character instead of ‘A’. For instance, if the specified work item is a bug, by putting #R<bug ID>, specified bug will be automatically changed to “resolved” after checking in changes.
All rules previously explained for work item association applies in the same way when specifying the ‘R’ character in the comment.
|
Quick tip: Work item associations are case insensitive, which means that ‘#A23’ and ‘#R25’ will be treated in the same way as ‘#a23’ and ‘#r25’ respectively. |
To illustrate how a work item (for example a bug) can be resolved, we have created a sample bug on a Team Foundation Server which ID is 1:
Since the created bug is currently active, let’s see if it can be automatically resolved if the bug ID is specified in the commit message. For the purpose of this article, we’ll assume that a change made in a SQL database should resolve a bug which ID is 1. With that being said, we’ll specify the following commit message:
#R1 Test check-in, to verify that the specified bug will be changed to resolved
After committing this change, let’s check the state for the specified bug:
Q: Is it possible to associate a work item when committing a change from the Object Explorer content menu?
A: No, this is not available when committing an object changes using the Object Explorer context menu commands
Q: Is this applicable to both, shared and dedicated database development models?
A: Yes, it is. Work item association with a changeset is available regardless of the used development model.
Q: Are work item associations related to Team Foundation Server only, or it is supported when working with other version control systems (Git, Mercurial, etc.)?
A: Work item association works for Team Foundation Server only.
Q: Is it possible to make additional modifications to a work item, after it is resolved as explained in the article?
A: Yes, this is possible. By resolving a work item as explained in the article, its state will be changed to Resolved. If for any reason a work item is not resolved with a checked-in changes the state can be reverted to Active.
