working folder help

grif · Post by **grif** » Thu May 06, 2004 3:14 pm

We are experiencing some issues that are difficult to describe and I'm hoping one of the great support people can point me in a direction to get these annoyances resolved.....
We have a root folder than contains two sub folders. One sub-folder contains a web-project (that has many subfolders in it). The other sub-folder has many sub-folders, each corresponding to a unique .csproj. We have set the working folder for the root folder to what we want. This is the only folder for which we specify a working folder.
The issue we are seeing is that after working in dev-studio for while, sometimes some of the sub-folders in the non-web-project folder have working paths set that are not derived from the root's working path. We branched our code and basically created a total copy of the mainstream development effort as our branch. We see some of the working paths in the branched codebase getting set to where the working folders should be set for the mainstream codebase. The crappy thing is that I have yet to find a way to consistently reproduce this behaviour - other than waiting until something isn't working right

-- otherwise I would post those detailed steps here. Its not always the same sub-folders that get set incorrectly, and they don't always get set to the same place.
So, I guess I have two main questions...
First, can VS.NET - with the integration with vault enabled - change the working paths within vault -- or is this something that can only be configured through the vault client (assuming there is no valut API stuff happening by us - we are only using the vault GUI client)? Secondly, does vault store the working paths for each machine, each user, each user from each machine, etc.?
We don't ever explicitly set the working path for any of the sub-folders, except for when we are trying to correct this issue - in this case we remove the folder in the "Set Working Folder" dialog so the working folder goes back to inheriting the working folder from its parent. Could this be because of something wrong we did when we branched the code? I'm really just guessing because I don't know everything about how vault works. Thanks for your time.

grif

ericsink · Post by **ericsink** » Thu May 06, 2004 4:21 pm

1. Yes, VS.NET can add working folder associations. In fact, I vaguely remember seeing situations where VS.NET adds working folder associations when it should *not* be doing so. (Does anyone else remember this?)

2. Working folder associations are stored on the client machine, per-user.

DarrenS · Post by **DarrenS** » Thu May 06, 2004 4:26 pm

I have seen this same behavior - where VS.NET takes it upon itself to mess with your working folder associations. I mentioned it here. To quote myself,

Another strange behavior I've noticed: at some apparently random times, the VS integration will "fix" the working folder for subprojects within Vault. Normally I'd like to only define the working folder for the topmost project, and have all the subprojects inherit and derive theirs from it. However, under certain circumstances (haven't figured out exactly when) I suddenly see the sub projects have their own, non-inherited subfolder. This causes no end of grief when getting projects from source control - they often don't end up where you expect locally. Is this a bug, by design, or unavoidable with the current version of Visual Studio? (I'm using VS .NET 2003)

dan · Post by **dan** » Thu May 06, 2004 6:29 pm

One problem here might be that if you branched the project in source control, Visual Studio still thinks your working folders are set to the old locations in Vault, even if you changed them in Vault.

See this MS knowledge base article for more info: http://support.microsoft.com/default.as ... -us;173065

grif · Post by **grif** » Fri May 07, 2004 7:37 am

I read the MS KB article you referenced - and found some people with similar issues from searching the newsgroups. The KB article contains a fix for devstudio (vc6, etc.), and all of our code is in VS.NET. Apparently, this is just a known issue for VS.NET?
This all seems pretty crappy. I understand that it may not be Vault's responsibility. I spent all day yesterday untangling this mess and it seems as though there is nothing we can do to prevent it. The only silver lining here is that at least I have discovered what was happening - and now I know what to look for when things get jacked again.
Is it worthwhile for you guys (at Vault) to invesitgate creating something that can properly update the source control bindings for our projects when we want to branch? Or is the integration with VS.NET something that is more difficult for you to support? I'm open to any other solutions you all may have for us. As I'm sure you can imagine, its terribly inconvenient to be overwriting files in a branch that you weren't working on because the working paths have been changed from underneath you.
grif

dan · Post by **dan** » Fri May 07, 2004 9:25 am

grif wrote:
Is it worthwhile for you guys (at Vault) to invesitgate creating something that can properly update the source control bindings for our projects when we want to branch? Or is the integration with VS.NET something that is more difficult for you to support? I'm open to any other solutions you all may have for us. As I'm sure you can imagine, its terribly inconvenient to be overwriting files in a branch that you weren't working on because the working paths have been changed from underneath you.
grif

I think to fix this, Vault would need to edit the solution or project files themselves, which is crossing a barrier that we really shouldn't (having the source control tool automatically modify files that are stored within it is asking for all kinds of trouble).

Perhaps the whidbey version will handle this better...