microsoft / vsts-work-item-migrator

WiMigrator is a command line tool for migrating work items between VSTS/TFS projects
MIT License
148 stars 69 forks source link

Querying for already existing work items seems to ignore project #47

Open tbergstedt opened 5 years ago

tbergstedt commented 5 years ago

We are in the situation where we have once successfully migrated a set of work items to a new team project in the same collection as the original project. When we now want to do this action again to another team project at a later time (short story: think of it as a way of "baselining" a set of work items and their states), the tool claims that a number of work items already have been migrated. So:

Migration 1: Original ==> Project 1, 10000 work items to migrate (success) Migration 2: Original ==> Project 2, 11000 work items to migrate (only the 1000 new ones are migrated)

It seems as if the status check whether a work item already has been migrated is cross-project, and then returns those work items that have been migrated to the previous project.

pelvark commented 5 years ago

@tbergstedt When the migration is done, all the migrated items are tagged. And if you perform another migration, these tagged items are not migrated again.

You could change the tag in the configuration file here: // the tag to stamp on the work items on the source project // once the migration is complete. "source-post-move-tag": "6F078B6C-2A96-453B-A7C3-EACE6E63BB97", // the tag to stamp on the work items on the target project // once the migration is complete. "target-post-move-tag": "6F078B6C-2A96-453B-A7C3-EACE6E63BB97",

Or you could make a bulk edit of the items that have the tag. This could be done by making a query for the tag, and targeting all the results with CTRL-A, right click and click edit. Then choose the option "Tags(Remove)" in the fields section and then write the tag in the value field and clicking OK.

tbergstedt commented 5 years ago

We had chosen not to create any tags, neither on source nor target items. And we used different configurations in the two migrations, so I don't think any usage/removal of tags would have helped us.

Maybe I wasn't really clear about this earlier, but our problem was that we actually needed to migrate all items once again (to a new target project), regardless of whether they had been included in the previous migration or not. (In the example above there could have been ~6 months between the two runs).

We have managed to circumvent this with some local code changes, but these aren't really up for publishing atm. Hopefully, we might get the time for this at a later date, if requested.

obvioussean commented 5 years ago

@tbergstedt Unfortunately the API used for checking for work item existence is not project scoped. With the latest updates to the REST APIs on AzDevOps I could support this, since they include the project in the url now. But that would be a potentially breaking change for existing migrations so I'll have to make it an opt-in type experience.