VS.NET 2003 Working Folders

[gmagana]

What's SourceGear's plan for future handling of the Working Folders issue with Visual Studio? I understand that in Vault 2.1 there will be a "recurse" checkbox to unset working folders recursively, but I get the feeling that SourceGear sees the problem as not their problem, and SourceGear just want's to move along...

I ask because I have just spent two hours fixing a mess where all I wanted to do was move a .sln file to another directory (one directory up). It turns out, that, once again, VS.NET created all sorts of subdirectories in Vault, covering its tracks by setting all sorts of working folders in Vault as to not have the user notice what happened... The problem is that the Vault directory structure then does not mirror reality, and as soon as you try to get the project/solution from another computer you have a huge, huge mess in your hands. This modification of the working directories also involves duplicating files sometimes, so that (copies of) the same file are now under different directories within Vault, thereby nicely defeating the whole purpose of version control. Now, unless one looks at the Vault client while doing these changes, these things can esily go unnoticed until one has a true mess in one's hands, with several versions of the same file saved as different files in different directories under Vault...

Does SourceGear even recognize this as a problem? Can Vault be forced to disallow setting of Working Folders (through any means) to force VS.NET to show errors instead of allowing it to cover its tracks?

To me working folder mismanagement is, by far, the biggest problem with VS.NET source control. As it is, I have to go back to my #2 machine and make sure I can retrieve a solution and its projects from scratch... It's really not reassuring to have to do this.

PS - One exception to the rule would be that web projects and their files are stored in the web server content path (c:\inetpub\wwwroot). This is really the only case where I see a Working Folder setting would be needed, aside from the root working folder from which inherited working folders get their path.

[dan]

The problem is that we can't make good or valid decisions from the Vault side for when to ignore working folder re-assignments. I would guess that Visual Studio changes the working folders when it moves files around, and expects them to be where it tells Vault it wants them to be. If we ignore where VS wants the files to be located, we would do so at the expense of cases where the files really are where VS says they are, which would cause far more problems.

Perhaps a work around for this would be to unbind the solution before moving files around, and then attempt to rebind after the move? The re-bind may or may not work, since it might still expect files in certain working folders, but it might be worth trying (on a test database).

So, sorry to disappoint you Gabriel. Maybe VS 2005 will be easier to control...

[gmagana]

Perhaps a work around for this would be to unbind the solution before moving files around, and then attempt to rebind after the move?

This will work... But how? How does an "un-bind" happen? Is it just by deleting the source control files that reside alongside the project/solution?

Maybe what is needed is a list of instructions on how to do things that involve Visual Studio, such as renaming a file. I have learned that to rename a file I have an easier time if I do the following: 1) Check-in file to be renamed, 2) rename file within VS (select the file press F2), 3) exit VS (or close the project/solution), 4) Vault still has the old name, so rename file within the Vault Client (this will push the revision number up), 5) do a "Get latest version" from the Vault client (even through there are no content changes), and 6) re-open the project/ solution on VS.

Really, that is a lot of steps just to rename a file, but the bigger problem is that it is not documented anywhere. Perhaps it might even not be the optimal way to rename a file, and so if there is a faster way, I'm sure all Vault users would appreciate knowing it!

Now as to my example of changing the location of a solution file for VS... What I ended up doing was just deleting the old solution file and creating a blank solution to which I added my existing projects. By then I had messed up my project configuration and had to hand-edit several project files to get everything back to normal, but everything would have been a lot easier if I had just created a blank solution file in the right directory from the beginning and added my existing projects to it rather than trying to move an existing solution file and its associated version control metadata while keeping the projects in the original locations.

Anyway my point is that it is really easy to get in trouble with VS if we follow the wrong steps, so mybe it would be a good idea to have an "if you want to do this, do that..." type of list for VS... Specifically a complete discussion of paths would help, since if we don't choose our paths wisely, VS will gladly recreate a subdirectory structure and not tell you.

[dan]

Yes, more instructions is always a good idea. I'll add to the list of KB articles that we want to write.