Team Foundation Server (TFS) 11 – Exploring Local Workspace Concept in TEE 11
Posted by: Subodh Sohoni
in Category VSTS & TFS (Azure DevOps)
Abstract: In this article, we will explore how the local workspaces concept works in Team Explorer Everywhere in TFS 11
Recently my friend Gian Maria Ricci wrote an excellent article on the subject of Local Workspace . Whereas he has scoped it to Visual Studio 11 with TFS 11, In this article, I will explore how the same things work with Team Explorer Everywhere (TEE) 11.
Let me begin by saying a few words about the problem with Server side workspace that was the only option till TFS 2010. Microsoft introduced the concept of Server side workspace in TFS 2005 and kept that concept unchanged in spite of a lot of criticism but finally has relented to provide local workspace as a default. The main design principal behind the server side workspace was the minimization of network traffic between TFS and the client, but that meant disconnect between the workspace object that was on the server, with the file system folder that was mapped to it. If any direct operation like add or delete takes place in Windows Explorer, then the workspace object does not come to know about it. If a file is deleted in windows explorer and when a Get Latest is done by the same user, TFS queries workspace object about the status of the file and since the workspace object has not come to know about the deletion of a file, it gives the wrong status (available) to TFS. The file is not transferred although it is not in the local folder.
Client workspace keeps the status of file system and the workspace in sync with each other. Whenever a change in the file system happens like addition of a file, it is detected by the workspace and a pending change of the type addition is recorded. Let us now practically check that this desired functionality is a reality. I used a Java project to check it.
I started Eclipse and Team Explorer Everywhere 11. While opening Eclipse, I was asked for which workspace folder do I want to use. This workspace is of Eclipse and works like a project (as mentioned by Gian in the earlier referred article.) I had created a folder at D:\ SSGS EMS Workspace which I provided for Eclipse workspace.
In the Java perspective, I opened the package explorer view. Now I created a new Java Project named ‘SSGS EMS Password Validator’ ensuring that the path being used is same as the workspace folder. I added a new Java Class named ‘PasswordValidator’ under the package named ‘SSGSEMS’ which created a file named ‘PasswordValidator.java’
A Team Project with the name ‘SSGS EMS’ already existed and I connected the Team Explorer to it. I opened the Source Control Explorer by clicking on the link for it in the team explorer. Using Pending Changes window, I created a new workspace named ‘SSGS EMS ’ and mapped it to the same folder D:\SSGS EMS Workspace that was used as a workspace folder of Eclipse too. I selected that workspace as default folder
Now I added the java project to the TFS source using Team > Share > Team Foundation Server menu item. I added it to the SSGS EMS team project. As soon as the source was added to the source control, I checked in the project.
When I opened the folder D:\Java\Workspace\SSGS EMS Password Validator\SSGSEMS’ I found the file ‘PasswordValidator.java’.
Now to begin the first check, I added a file named ‘ValidationLogic.java’ (which I had created earlier) in the same folder.
In Eclipse, when I refreshed the Java perspective, I could see the ValidationLogic.java in Package Explorer, Pending Changes Window and Source control explorer with Add operation on it, in the last two places.
I checked in the newly added file ValidationLogic.java.
As a next step of the local workspace check, I reopened the windows explorer and deleted the ValidationLogic.java file. This change was not detected by the workspace or at the least it was not shown in the pending changes window. I somehow had expected it to happen.
I now did a Get Latest operation on the entire project.
As I expected, the file was added back in the folder as well as in the Java project.
As a last check, I renamed the file to ‘PasswordValidationLogic.java’ in the windows explorer. I expected that this change will be picked up by workspace and a pending change will be shown.
The rename was picked up nicely by Java Project but the pending change shown was of Add type for the file named ‘PasswordValidationLogic.java’. The original file ‘ValidationLogic.java’ was retained as it is in Source Control Explorer
I checked in the file after rename. It put both the files in source control explorer and then afterwards, when I did a Get Latest, it brought the file with original name ‘ValidationLogic.java’ also in the folder and Java Project. This is something I find a bit jarring since one unnecessary file now exists in my project.
In the nutshell , Microsoft has honored the popular demand of keeping Windows Explorer and Source Control Explorer in sync with each other but I find some part of the feature yet having rough edges. May be this is still a Beta product, I hope those will be ground and smoothened by the time of RTM.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!