Hi Geoff and Rupa,

This issue is seen in both clients. The users who are seeing this and mentioning it to me now are using the Eclipse client.

However, the issue appears to be this (I apologize for the lengthy post. I have documented as much as possible here to show you what I did):

If you have your sandbox for your workspaces set up as C:\Workspaces and you change it to C:\RTC, the metadata for the new sandbox is still captured under C:Workspaces (if the folder named C:Workspaces still exists). There is a way to change this using RTC.

Here is the use case:

1. Users on a team here were creating workspaces for several months under C:\RTC2.0. Most of the team was using RTC Eclipse client just fine this way. Others had C:\RTC for the workspaces path.

2. There is now a need to "Standardize" how the workspaces are setup. So they asked me about it. I said "No problem, just pick something like C:\RTC and create new workspaces under that new workspace path. It should be simple enough." So, based on that, the new standard for workspace paths was going to be "C:\RTC".

3. Most users were just going to "switch" their sandboxes from C:\RTC2.0 to C:\RTC. A couple of them were just setting up RTC for the first time and would be using C:\RTC from the start for their sandbox.

4. The users who "switched" to C:\RTC removed their existing workspaces under C:\RTC2.0 using the Unload action in RTC. Then they shut down their RTC Eclipse client. When they reopened it, they were brought to the RTC Welcome screen. This was expected (or rather "not unexpected") and I had the users log into RTC using the correct Connection URL and their RTC logins.

5. The users were able to create new workspaces under the new sandbox (C:\RTC) and continue working.

6. One of the users noticed that even though he had removed C:\RTC2.0 on his PC that it reappeared again after restarting the RTC Eclipse client. We both looked at it and noticed that there was a folder named .metadata under it. We figured that this was just some latency information that was cached and that it would eventually go away. So, the user left it there. It was not hurting anything by leaving it there. This also happened t the other users who switched from C:\RTC2.0 to C:\RTC. They also had no problem leaving the old C:\RTC2.0 folder on their PCs.

After discussing this post with Geoff I realized that the old .metadata folder is not going to go away. At least not without taking one more step.
1. In the Eclipse client, from the top menu bar select File->Switch Workspace.
2. From the drop down menu, from the list of workspace paths displayed (C:\RTC2.0 was in this list), select Other...
3. In the dialog labeled Workspace Launcher, either enter in the new Workspace folder name or Browse to it (i.e., if C:\RTC already existed).
4. In our case, users entered C:\RTC. This created a new folder named .metadata under C:\RTC. All workspaces under C:\RTC are now seen in the Pending Changes view, whether or not Incoming/Outgoing Changes are detected.
OK that was actually 4 steps. But, the end result was what our users here expect and this makes them happy.

This is just an observation on my part: Perhaps in a future release, RTC will automatically add a .metadata folder under a new workspace path. That is, when I switch from C:\RTC2.0 to C:\RTC and create new workspaces under C:\RTC a new .metadata folder will be created there without having to manually run the Workspace Launcher. I believe that the information entered in that dialog is cached and used by RTC. This is not a bad thing. I think it would be nice to be able to switch the location "on the fly".

One other thing: In the Eclipse Client, when I select Window-->Preferences->expand Team->expand Jazz Source Control and then select "Sandboxes", all of the ones on my PC do show up in the window labeled "Configure which folders are known and tracked by the Pending Changes view". When I originally reported this issue only 2 of the workspaces under one of the workspace paths (C:\RTC2.0) were displayed in the Pending Changes view. Based on what I was seeing when I originally reported this issue, I am not sure that this is working.

As I mentioned before, we also have several workspaces set up as "Do not load anything. The workspace will be tracked by the Pending Changes view" on our workstation that we do builds on. I just went on there and for several of the workspaces that I knew had Incoming Changes, I had to run the load action on them (using the Eclipse Client). To me, this is not a big issue. If there was a build request for builds using those workspaces, the build action would force "Accept Pending Changes" during the build. Most users of RTC here do not set up their workspaces with "Do not load anything. The workspace will be tracked by the Pending Changes view". So, this is also just an observation.

So, I now understand what is happening in this case and I now know how to resolve this type of issue.

I will look into the Work Item that Rupa entered. Thanks for the responses and the help. It really is appreciated.

-Walter

Hi Rupa,

In Walter's original message in this thread, he indicated he was using
the Eclipse client (all of my comments above were about the Eclipse
client).

Walter: Are your teammates also using the Eclipse client, or are they
using the VS client? (If the latter, Rupa's message probably explains
what they are seeing).

Cheers,
Geoff

sreerupa wrote:

Hi Walter,
If you do not load a workspace and just track it, the VS Client
does not save that information across sessions. From the forum
discussion, it looks like your workspace issues started after you
migrated to 2.0.0.2 iFix2 - which surprises me somewhat. Earlier, the
scm daemon used to maintain this information. Now it does not any
more, so this information needs to be maintained on the client side
preferences - something we haven't implemented yet. I'm trying to
remember when this change happened - it was definitely earlier than
2.0.0.2 iFix 2 I'd think.
If this is big pain point, we could try to get it in 2.0.0.2 iFix
3 - it'll be somewhat tight though. If not, we'll definitely address
it in 3.0.
I've opened
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/114291
to track this - please add your comments there.

regards
--Rupa