不同TFS项目中的代码审查，变更集和看板工作项

Question

Where I work, the Kanban is in a different TFS Project than the code (I know...don't ask). Of course, this means the underlying change set & the work item are in DIFFERENT TFS Projects.

Now...

I know merging code between TFS Projects is Baseless & that Baseless merges should be avoided, because, unlike a merge, they disregard the history of either side on the merge.

So my questions are:

Q: Does associating a check-in to a WORK-ITEM in a DIFFERENT PROJECT make it "baseless" in some manner?
Q: Does associating a check-in to a CODE REVIEW in a DIFFERENT PROJECT make it "baseless" in some manner?

Doing so isn't breaking anything.

I get no exceptions, but what is the affect?

Answer 1

Associating a changeset from Project A with a Work Item in Project B is fine. There will simply be a Changeset link added to the Work Item which points to the code stored in the other project. It won't attempt to do any weird merging of the code change into Project B.

Under the covers, a Code Review is really just a Work Item that points to a Shelveset so it's the same as the above scenario, no problem having them in separate projects and it won't affect Project B's source code. The trick here is that you likely want to create the Code Review work item in Project B and the easiest way is to make sure that Team Explorer is pointing at Project B rather than Project A.

Having Work Items and code in separate projects isn't ideal but it is pretty common. Some of the biggest pains I find are:

• When you open a .sln in Project A, Team Explorer always connects to that Team Project and you have to manually switch it to Project B where your Work Items are stored.
• Where do your builds live? It's easiest to have them in Project A with the code but then you can't see them easily on the Project B dashboard where people will be monitoring project progress.
• Test Cases, Reporting and other things have some inconveniences....

If it is confusing for devs, you might want to lock down Project A so that you can't create Work Items in it, then lock down Project B so it can't store any code. This of course, assumes that Project B has no code and Project A has no Work Items.

Hey, it could be worse, WIs and code could be in separate Project Collections :-)