This is my first attempt at creating linked work items in TFS. I'm using VS2010 TFS with the Agile template out of the box. I created a Requirements type Work Item for creating a class specifying several requirements. In Test Driven Design style I created a test project with tests for the requirements.
Now I would like to link the Requirements Work Item to the source code file with the tests. When I select the All Links tab in the Work Item window and then use the Link to button the dialog it brings up won't let me specify a source file. It seems to only want to link to another Work Item. I'd like to link it to the source file so when the requirements change there will be a link to the test source file to be changed. Is there a way to do this. Thanks in advance.
Jon Newbill
The way TFS associates work items with code is at checkin. One of the reasons for this is that a source file might implement many requirements, tasks and bug fixes over time. You want to associate the changes to the file to a work item, not the file itself.
A requirement (or bug fix or task) might involve changes to multiple files so you should checkin files in logical groups. I.e. if you've changed 3 source files and a config file to fix a bug then you can check those files in separately and associate the changes to the bug work item at each checkin. You could also check in all 4 files at the same time and associate that single checkin to the work item.
If you change 3 source files and a config file to fix a bug, and you have also changed another source file to add extra functionality, you should avoid checking this file in with the others as it will be held in the same changeset and associated with the same work items as the bug fix code.
In your specific case, if the requirements change then I think you should probably create a new work item. That way you can see the code that implemented the original requirement and the changes to the file will be associated to the change in requirements.
You can associate changesets to Work Items as seen in this picture
Related
I have 2 solution in my repository: "A" and "B" under main\A & main\B
the problem that I'm trying to solve is that when I'm changing some file in "A" I can see those file and deliver them when I'm working solution "B".
Can I set a .tfignore file per solution and have it ignore all the other files that does not exist out side of the current solution?
If "A" have his own build definition in TFS, Can I enforce the change-set to include only files from "A" folder?
.tfignore could not achieve what your want. You could use below workarounds:
Best practice: A developer can check in pending changes limited to a given folder/branch/solution by right-clicking the
folder/solution, choosing "Check in". For that check-in action, the "Pending Changes" view will temporarily "exclude" any changes made
outside of that folder/branch/solution until you complete the
check-in.
Can it be prevented: There is a premade Check-in Policy option known as "Enforce check-in to only contain files that are part of
current solution". This may work for you, since you are using
"Solutions".
More details info please refer this simialr question: Why does TFS allow a single changeset to affect multiple branches? If there isn't a very good reason, can this be prevented? and several ways per each project.
What you should actually do in this case is create two workspaces, one for each project. You can then switch between the workspaces as necessary and only see changed files within that workspace.
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I have a C# solution I created within Visual Studio 2010 Ultimate that contains multiple projects that make use of the same structures, classes, and enumerated types. I have created a .cs file that contains all of these items, but at the moment I have to make a duplicate of this file for each project. This is obviously less than ideal because I have to remember to update each copy of the file should I make a change or addition.
Is there are way I can have all of the projects reference just one actual copy of this file, so that I only have to update it once and all of the other projects can see this update? A colleague of mine told me it was possible to make some sort of "symbolic" reference in TFS, but since I don't really know what the name of this feature is I don't know how to research it further.
This question has answers that suggest either creating a class library or using "Add as link" when adding an existing item. I suppose I can do this in Visual Studio when not using TFS, but I have posed this as a TFS-specific question. Will this "add as link" option work when TFS is in use or do I have to do something in TFS to get it to honor the link reference?
"Add link" option would definitely work with TFS. You dont have to do anything specific for that. "Add Link" is project specific and it will add a new entry to your project file specifying the location of your .CS file. As long as the file is available in the particular location during server build, there is nothing to worry. Make sure that the Add link makes a relative path to the file and not absolute.
In my company, we have multiple projects within a solution and we share a single "Assemblyversion.cs" for all the projects so that I dont need to write version info in multiple files. We have made use of Add Link and it works great!
Shouldn't vcxproj.filters be embedded in the .vcxproj? As it stands I have to check this in to source control so others can see the folder structuring in the solution.
According to what Dan Moseley says in this question, they also wanted to separate the tree structure from the build specific information because changing the tree structure would cause an update to be made to the project file, and that in turn would trigger a rebuild. By moving the logical view of the project to a separate file this is avoided.
They were embedded in fact, in previous versions of Visual Studio. The extension was still .vcproj and the filters were stored inside the project file. However, as of 2010 it was decided to pull the .filter information into a separate file.
It is really up to the design teams now to decide whether to add this source control or not. If you want all the developers to have the same structure (for reasons of communication) it might be wise to check them in. If you want to allow each developer to use their own logical view, then don't.
The vcxproj file contains the commands for the msbuild environment. So it contains the files that should be built and the arguments for the compiler how to build/link etc. the source files.
Due to this, the development team decided that the 'view' of the files in the solution explorer should not be contained in the msbuild file, but in another file.
So this was done to separate the build settings from the view you have.
We have a StarTeam view that has two files that are in the "Unknown" state – does anyone understand why they are in this state and/or how we can get them out of the state?
Is deleting them and re-adding them with a different name the only solution?
Note that if you check out these two files (regularly or using “force checkout”), they will always be listed as “Unknown” (annoying).
Thanks.
More info based on Craig's suggestions below:
a) Calculating file status using MD5 checksum: same results ("Unknown" status)
b) These two files in question have only one revision on the server. I'm not sure if this is because our CM group attempted to fix the issue by deleting and recreating the files or if there really was just one revision. The files are text files.
c) I tried deleting the files on my local machine and refreshing the status. When I do this, instead of seeing the two files listed as "Unknown", I see a total of four files listed with a status of "Missing". There are two entries listed for each file - each pair has the same file name, folder path, "modified by", and "file stamp at time of check in". I have no idea why each file is listed twice. If I select each entry in a pair and select "Compare Contents", my diff tool says they are identical.
I have this same weird issue with the four files whether I use the MD5 checksum compare or non MD5.
If I try to checkout all four of the Missing files, I get two alerts prompting me to merge the files. I say no, the files are now on my local file system and the status is back to where I started - two files listed as "Unknown".
Craig's update:
You're definitely on to something. I moved each of the duplicate items to another directory. That immediately solved the issue in that I now could checkout the four items (two in same dir and two in new dir) without any "Unknown" items. I then deleted the two items that I moved to the new directory.
In doing this, I saw some more info. We somehow have a directory structure like this:
Parent_Dir
--SubDir1
--SubDir1
--SubDir1
--SubDir1 <- Two items were here
--SubDir1 <- Two items were here
--SubDir2
--SubDir3
--SubDir4
--SubDir5
Somehow we have five sub directories with the same name and these two files in question existed in two of the sub dirs with the same name.
The issue appears to be resolved. Do you think I should manually delete the extra sub directories?
Thanks to Craig this issue appears resolved. I have no idea how this situation was created (anyone?) but.. we're good now. Thanks Craig!
It would be a huge mistake to delete the files before you determine where the problem lies. Deleting and re-adding the file would kill the history and any links to the file. It also might not fix the problem, due to the way that StarTeam works internally (with a Native-II repository, anyway). Deleting the file and re-adding the identical file will not actually update anything in the repository, except the pointers to that revision. The revision itself would have stayed there when you deleted the file, and re-adding it would just create a new pointer to that revision.
If you haven't done so already, I strongly recommend telling StarTeam to calculate the file status using an MD5 checksum. Do this in the client via Tools->Personal Options->File->Use file checksums to calculate status. Then try update status again. This is not the default setting (in at least some versions of StarTeam), so it's worth checking. If you have not already done this, it may, by itself, fix the problem.
The first thing to do is to determine if the revision is valid on the server. If the files are text, the easiest way to do that is to compare contents between that revision and the previous revision. If it does turn out that the revision is corrupt, then the best solution would be to check out an earlier revision, and then force check in. This way you preserve the history of the file.
If the file appears to be OK on the server, then test it locally, by comparing contents. If the file is corrupt locally, do feel free to delete the file locally and then check it out again. Unlike deleting the file on the server, you don't lose anything by doing this, except local revisions.
If these suggestions do not fix the problem, I still would not recommend deleting the files on the server. Tell me the results of your investigations back here, and we'll see where we can go from there. It is, in my opinion, nearly always mistake to kill history.
Update
Based on the updated information in the post, I'm getting a better sense of what is going on here. It is likely that there are two items which point to the same file, and have the same name. "Item" is a concept in StarTeam related to the fact that a single file, change request, requirement, etc. can live in multiple places at once. For example, you can have a single file in two different views or projects.
Generally, you do not have the items with the same name in the same folder. But it can happen. And that probably explains the "Unknown" status. When you tell StarTeam to compare the file on disk with the item of the same name on the server, perhaps it can't figure out which item it should look at.
The first thing I would try is to try and drag one of the two items somewhere else. If that fixes the problem in the folder in question, you can delete the item elsewhere, without affecting the item in the folder. If, on the other hand, dragging one of the items elsewhere causes them both to move, it's easy to drag the item(s) back to where they came from.
Update 2
Do you think I should manually delete the extra sub directories?
Yes, but just as with the files, move them first, and make sure the subdirectories you'd like to keep are unaffected before deleting them.
A good way to identify this issue if it comes up again is to click on the root folder, add folder path to the shown columns, then click the all descendants button. Sort the files by name, and look for the unknown files and see if multiple files of the same name are checking out to the same path. Usually this is the result of a mistaken share, addition, or a change in folder check-out path.
As it is undetermined what order StarTeam will check files out, having two different files with the same name pointing to the same local location is a mistake. The 2005R2 native Windows client and Cross Platform client would pull files in a slightly different order, causing views with this issue to produce checkouts with different files.
There are a few ways to legitimately end up with this situation - keeping multiple branches of a single file on the tip and designating which to use by view label is a common one. StarTeam is one of the few VCs that can handle multiple references like this.
Separately, if you can help it, never delete and re-add a file. 99% of the time, it isn't what you want to do. Re-adding a file to the server gives it a whole new archive in the database and it will not be tied in any way to existing shares of that file. You will also lose all of your revision history. Instead, look for ways to move files. And if you have multiple files with the same name and content on your server, it is usually a good idea to make an effort to share the file to the various places it should exist rather than re-add it. This will make sure your changes propagate so you don't need to check-in fixes multiple times.
Were those files added twice? You can add the same file multiple times which could result in this error. Also, check the Reference tab - are these linked files to elsewhere in the repository?
Could that be the files or their status got corrupted on the server? In that case, delete and re-add is the only way.