One of the areas with no potential for confusion, and yet where still some confusion occurs, is the caching of the work items opened in Visual Studio. For performance reasons, Work Item Tracking integration package caches work items the user opens, and that may lead to somewhat unexpected results. Let's look the following scenario: At that stage, if user A does not refresh the work item (by closing and reopening it, or by using Edit->Refresh Work Item menu), the data in the work item is outdated, since Visual Studio integration does not support push model (where server pushes changes to the client), rather using pull model (client pulls changes when user requests for it). Now, let us complicate the scenario a bit. It may not be so obvious, but if user A runs Team Query that returns work item 1 and views or opens it from the query results, he will have a cached work item data in his instance of Visual Studio. In that case, to update the work item user may re-run the query, or use Edit->Refresh Selected Work Item menu. Overall, general rule is this: if you have work item opened in Visual Studio (either in separate window or as part of the query result), then you have cached data, and if somebody is updating your work items in parallel, you would be better off refreshing the work item before editing it. If you edited old revision of work item, on save you will be prompted to refresh your work item prior to making any changes (and, er, will lose your edits).
Monday, March 10, 2008
Simple yet not so simple - caching work items in Visual Studio
3 comments:
Hi. I'm Gregg Boer, and I work on the Team Foundation Server team, specifically on Work Item Tracking. The behavior you describe, which happens as a result of caching the work item, has been a source of debate on our team. We know there is some (lots of?) confusion with the current behavior. But are trying to figure out what the behavior SHOULD be. We don't want to make a database hit each time to see if there is a later version of the work item.
Does anyone have any suggestions for this?
Gregg,
I'm not sure why you wouldn't want to make a quick database call if data integrity is the important thing, but let me suggest a couple of things...
What if once a user started editing a work item, that item became locked on the server until it was released (or maybe just timed out), to avoid concurent edits?
Whatever you do, the behavior should be consistent between the VS.NET front-end and the Teamplane web front end.
If everything is stored in XML maybe you could use the same merge behavior you have with code? Displaying raw XML would be hard, but maybe if the front-end were XAML? Or maybe you could just display the conflicts and let users choose which to accept before "check-in" of the work-item?
Forget merging, first of all that would require complete versioning of all previous versions of a workitem, not to mention that the merge of two changes might not make sense (One writes a solution proposal, and another writes a rejection reason ... in two different fields, so they merge just fine)
Locking would be a lot better, but then that might prevent the build numbers to be associated with the work items because the work items were locked when TFS were building
However it would be nice to have a versioning check once editing starts, with the option of refreshing the workitem before continuing.
Post a Comment