The item $/Feb08 does not exist at the specified version.
I have created several new projects in TFS recently. Most of the developers are not having any problems but a few are getting the error "The item $/Feb08 does not exist at the specified version." Althought the are getting the same error what they are unable to do is different.
Some developers are able to see the project but are unable to download specific folders. Some are able to see the project and files and get latest version from source control but when they attempt to check out the file they get the error.
I have checked permissions and they are set correctly. I have deleted their workspaces and their local files and they continue to get the error.
- Changed TypeBill.WangMSFT, ModeratorWednesday, December 24, 2008 5:50 AMChange back to question.
Answers
- We solved this by giving the users rights at $/project. We have all users set up in groups. We have given every group read rights at $/project. Additional rights are set at $/project/subfolder.
- Marked As Answer byBill.WangMSFT, ModeratorWednesday, December 24, 2008 5:50 AM
All Replies
A few questions
- how are you trying to perform the operations, through command line or from the UI?
- Are the users seeing the same problems for the same paths or for different paths? could you please send an example of the paths that are causing this and the workspace mapping for one of the workspaces
- Are all users seeing the error for $/Feb08 or depending on the path they are trying to perform the opration on?
Please have a look at this post, which version are you using?
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1567934&SiteID=1
- They are using the Visual Studio Team Edition for Developers UI.
For example they are having trouble checking out\downloading $\FEB08\FEB08GBL\Applications\Websites\...\default.aspx and the error is saying "The item $/FEB08 does not exist at the specified version." From this same workstation you can get latest and view history of that file.
They are having this problem in multiple projects. Both $/FEB08 and $/TWC were created recently and seeing the same error. The error shows the respective project that they are having problems with.
- They are seeing the problem for different paths. Basically once they get the error the problem persists on that machine even if they create a new workspace mapped to a new local folder. I used command line to delete 3 workspaces off of one machine and then mapped the workspace to C:\10L\FEB08. I continued to get the same error. Each of the developers are choosing where they map the code on their local machine so the path is different for each machine. Another example is C:\From TFS\FEB08.
As a reminder not all developers are experiencing this problem.
Which VS version are you using?
Could you please try to go to one of the workspaces and check the mappings? are there any mappings that are unecessary? do you map the root folder only?
We are using VS 2005
I am currently working on getting it working on one machine. I deleted all workspaces through command line. When I opened up VS again it had recreated one of the workspace that I had just deleted. I then got the latest through the UI and mapped the root folder to C:\10L. The files where then dowloaded to C:\10L\FEB08\FEB08GBL and C:\10L\FEB08\Development. There is only one mapping on that machine.
"When I opened up VS again it had recreated one of the workspace that I had just deleted."
What is the command you used to delete the workspace? if you used tf workspaces /remove then the workspace was deleted from the cache onle, if you use tf workspace /delete or si,ply removed the worksapce from the UI it should not be re-created by VS.
I used
tf workspace /delete /server:JackSparrow w4170079;ad\ra214145
Something is odd about the behavior that you are describing, VS should not recreate a workspace once it is deleted. not sure if this can be a caching problem, you can try the following
from command line
tf workspace /delete /server:JackSparrow w4170079
tf workspaces /remove:* /server:JackSparrow ( clean up the cache)
tf workspaces /server:JackSparrow ( to update your cache)
tf workspace /new w4170079 /server:JackSparrow , from the workspace dialog add the mappings that you want. try to do a get to update the workspace and perform any action to see if you still get the same issue
- That worked to successfully delete the workspace but I am still getting the original error.
David, can you run a few queies on your database server and let me know the results.
First lets try to pin down version information for the file(s) they are having issues with.
Find a machine and workspace that are reproing the problem.
Get the local path and server path.
Run:
SELECT * FROM tbl_Version where FullPath = '$\...\'
Make sure you have the fully qualified path and the SQL stores all paths with \ not /. There is also a trailing \ on all items including file.
SELECT * FROM tbl_LocalVersion where LocalItem = 'C:\...\'
Make sure this is the local path the user has the mapped. Again follow the same as te path above, use \ with a trailing \.
SELECT * FROM tbl_Permission
This should be enough information to figure out why they are having a hard time accessing the items.
Thanks
I ran the queries suggested. Here are the results:
SELECT
* FROM tbl_Version where FullPath = '$\FEB08\FEB08GBL\>Build\>config-util.cmd\'--5319 2147483647 272215 68 $\FEB08\FEB08GBL\>Build\>config-util.cmd\ 1252 0 61050 5
SELECT
* FROM tbl_LocalVersion where LocalItem = 'C:\10L\FEB08\FEB08GBL\>Build\>config-util.cmd\'--57 272215 5319 C:\10L\FEB08\FEB08GBL\>Build\>config-util.cmd\ 6
--470 272215 5319 C:\10L\FEB08\FEB08GBL\>Build\>config-util.cmd\ 6
--300 272215 5319 C:\10L\FEB08\FEB08GBL\>Build\>config-util.cmd\ 6
--332 272215 5319 C:\10L\FEB08\FEB08GBL\>Build\>config-util.cmd\ 6
SELECT
* FROM tbl_Permission--0 2 62 0
--0 3 62 0
--0 4 62 0
--0 5 0 0
--0 42 0 0
--1 $\ 2 3583 0
--1 $\ 3 3583 0
--1 $\FEB08\ 2 0 0
--1 $\FEB08\ 3 0 0
--1 $\FEB08\ 250 3583 0
--1 $\FEB08\ 251 31 0
--1 $\FEB08\ 252 1 0
--1 $\FEB08\ 253 31 0
--1 $\FEB08\ 260 1 0
--1 $\FEB08\Development\ 2 3583 0
--1 $\FEB08\Development\ 220 3583 0
--1 $\FEB08\Development\ 256 2559 0
--1 $\FEB08\Development\ 257 15 0
--1 $\FEB08\Development\ 260 1 0
--1 $\FEB08\Development\>framework\ 171 3582 0
--1 $\FEB08\Development\>framework\ 172 1 0
--1 $\FEB08\Development\>framework\ 173 0 0
--1 $\FEB08\Development\>framework\ 174 30 0
--1 $\FEB08\Development\>framework\ 190 0 0
--1 $\FEB08\Development\>framework\ 191 3568 0
--1 $\FEB08\Development\>framework\ 192 0 0
--1 $\FEB08\Development\>framework\ 193 0 0
--1 $\FEB08\Development\>framework\ 220 3583 0
--1 $\FEB08\Development\>framework\ 249 0 0
--1 $\FEB08\FEB08GBL\ 2 3583 0
--1 $\FEB08\FEB08GBL\ 3 1 0
--1 $\FEB08\FEB08GBL\ 220 3583 0
--1 $\FEB08\FEB08GBL\ 256 2559 0
--1 $\FEB08\FEB08GBL\ 257 1 0
--1 $\FEB08\FEB08GBL\>framework\ 171 3582 0
--1 $\FEB08\FEB08GBL\>framework\ 172 1 0
--1 $\FEB08\FEB08GBL\>framework\ 173 0 0
--1 $\FEB08\FEB08GBL\>framework\ 174 30 0
--1 $\FEB08\FEB08GBL\>framework\ 190 0 0
--1 $\FEB08\FEB08GBL\>framework\ 191 3568 0
--1 $\FEB08\FEB08GBL\>framework\ 192 0 0
--1 $\FEB08\FEB08GBL\>framework\ 193 0 0
--1 $\FEB08\FEB08GBL\>framework\ 220 3583 0
--1 $\FEB08\FEB08GBL\>framework\ 249 0 0
I also did some other research. I tried to perform the operations from the command line to see if it gave any more details. What I found was that the Check Out operation would work from the command line but not from Visual Studio. I thought this was strange. However, the Check In command fails using either interface. I listed the outcomes of my research in the table below. When it says "Fail" it means it got the same error discussed in the previous post.
Action VS IDE Command Line
View History Good Good
Get Latest Good Good
Check Out Fail Good
Undo Checkout Good Good
Check In Fail Fail
HI David,
Are you still looking for help with this?
Matt
I don't know if David is but I'm starting to see the same problem.
On one project, two developers cannot check out any files - they get the "The item $/nnnn does not exist at the specified version" message. The rest of us have had no problems. I created another test project and so far the problem has not shown up there for anyone.
We're running TFS 2008, WSS 3.0, SqlServer 2005, and Team Explorer 2008.
I've changed permissions on the project and source control, removed and created workspaces, removed and added source trees and still have the same problem.
Does anyone know of something I could try? The only thing I can think of is to migrate our source to a new project and see if it behaves better.
Thanks,
Kevin
- Have you tried to run the queries posted by Carig Harry in this post and check the results?
I've moved all of the data to another project which has worked fairly well so far, except for reporting - the problems with which I've documented here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2892939&SiteID=1
- We were able to resolve this. We gave each group/person read access at the PROJECT level and it fixed the issue. We had been giving permissions only at the branch level. For most of the developers it worked fine but with a few we had issues. Currently we give read access to everyone at the project level and then give specific rights where needed inside the project.
- We have the same issue and with the last directions, give read permissions to the user at project level, it works perfectly, thanks to all!!
We are experiencing the same problem, when we try to get a bit more granular with our security. We are attempting to set security at the [project]\subfolder level. The source control explorer shows the project correctly, limited to only the project with specified user rights. The user can do a get latest version fine, but can not check out for edit.
I did delete and create a new workspace, and a new target workspace folder. What is interesting is that this user has no problem when his permission is set to admin level (imagine that). The permissions granted to the user are TFS Contributor/WSS Contributor/RSS Reader.
Next week, I'll run the query specified in other posts and report back.
- We solved this by giving the users rights at $/project. We have all users set up in groups. We have given every group read rights at $/project. Additional rights are set at $/project/subfolder.
- Marked As Answer byBill.WangMSFT, ModeratorWednesday, December 24, 2008 5:50 AM
Thanks! That did the trick.


