Workspaces corrupted?
Ocassionally we get users that claim they can't undo a pending change. It keeps saying there is nothing to undo. Or there is some errors merging files, or various other workspace type issues.
One thing I noticed is when I use the status sidekick I will often see the local path instead of having a local path looks like a server path (can tell because it has a $ in front like $/Myteamproject/dir/dir2 etc.) in the local path.
Usually the only thing I can think of to get things working is to do the "TF GET" sync from the command line.
1. This seems like a bug that workspaces can get corrupted
2. It seems even worse there seems to be no way to correct issues like these from the GUI
3. Doing that sync pulls down the entire workspace which if big is very annoying and space consuming.
4. How can we avoid having the corruption haapen in the first place?
[922 byte] By [
WXS123] at [2008-1-10]
We are always glad to help resolve your issues.
It would be great if we could get more details such as the undo command that was tried and the error that was reported. Same goes for merging and workspace issues.
About "tf get" command getting the entire workspace, you can scope down the get to a working folder by specifying a folder path and "/r" option.
1. This seems like a bug that workspaces can get corrupted
When you suspect that a workspace is corrupted, please let us know what prompt you to think so. Commands and error messages would be great.
2. It seems even worse there seems to be no way to correct issues like these from the GUI
The "tf get" equivalent is accessible from Visual Studio's Source Control Explorer.
3. Doing that sync pulls down the entire workspace which if big is very annoying and space consuming.
By definition, doing a workspace get will get all files/folders mapped in the workspace. If the workspace was previously synced, doing another get should not need anymore space than what is mapped. If there are some folder that you do not need locally, you can modified the workspace mappings. You can do this with "tf workspace" or from Visual Studio File > Source Control > Manager Workspaces.
4. How can we avoid having the corruption haapen in the first place?
Like in #1, commands and error messages would be great to help us narrow down the issues.
-Tan
One question from me - is it possible that user is changing mappings in the workspace and doesn't do "get" afterwards? This can lead to very confusing behavior of tfs.
Sometimes maybe the user does a change and they forget sometimes not.
Go to this link and do the operations there then try to shelve after them and it will fail with an error:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2173058&SiteID=1
You will notice local path shows like a server source control path and seems corrupted. Undo works in this case but this is one example of what seems like corruption and some type of impact.
I posted an explanation of the consequences of unshelving an add and ignoring the resulting conflict.
-Tan
 Tan Phan wrote: |
| I posted an explanation of the consequences of unshelving an add and ignoring the resulting conflict. -Tan | |
But how come I can't shelve my changes after I've done that?
You need to either resolve the ignored conflict to get the final file content for the ADD or undo the pending incomplete ADD. Then try reshelve.
-Tan
| Tan Phan wrote: |
| You need to either resolve the ignored conflict to get the final file content for the ADD or undo the pending incomplete ADD. Then try reshelve. -Tan | |
A few points I would like to make:
1. You should allow developers to shelve code at ANY time (it's ok to warn the developer, but it's NOT ok to stop them). This is like saving a file to a developer (or a set of files). MS Word would never tell the user, sorry you can't save right now your spelling is bad.
2. I'd say the error messages would need to be greatly improved since I think the error in that case is something completely unknown, like: unable to download file, and then the shelve fails.
3. You should always allow a developer to unshelve, even if files are exclusive locked (just allow developers to put the files somewhere without checking out, you can warn them but allow it.) Those files are like a backup to developers they get really perturbed when they can't get them.
Thanks.
The inability to shelve again is due to the incomplete/not-yet-downloaded Add that was unshelved earlier. So as far as the server knows, the content for the Add is not ready and, if the content is not ready, the file cannot be shelved.
If we eliminate the possibility of that incomplete Add from the shelveset, we would not be in this situation. I already agree with you in the other threads that we have problem workflow and that we will revisit and will take your recommendations into consideration.
About your points:
1. Agreed - with note above about the not-yet-downloaded Add. I am pretty sure we don't block shelving.
2. Agreed. For the attempted reshelve, I checked and saw that we already provide an error message indicating that the file was not downloaded.
3. I am not sure about the exclusive lock but we definitely have rooms for improvements in unshelving. One thing to note, which you may already know, is that you can cherry-pick which files to unshelve and the user can skip the troubled ones.
Hope this helps. -Tan
