Workspace folder mapping bug?
I have a directory at C:\Projects\Foo\Src\Runtime\EncryptionLib\UnitTests that I branched to location $/Foo/Branches/Developer/hillr/Exp_UnitTests. I then try to cloak $/Foo/Src/Runtime/EncryptionLib/UnitTest and then map $/Foo/Branches/Developer/hillr/Exp_UnitTests/UnitTests to C:\Project\Foo\Src\Runtime\EncryptionLib\UnitTests. VSTS gets confused. When I edit files in the UnitTests dir in this worksapce they are really being edited on the trunk instead of my private branch. When I go back to the Workspace mapping it has removed the two lines I added and put in:
active $/Foo/Src/Runtime/EncryptionLib <missing an extra EncryptionLib here>
C:\Projects\Foo\Src\Runtime\EncryptionLib\EncryptionLib
active $/Foo/Src/Runtime/EncryptionLib/UnitTests
C:\Projects\Foo\Src\Runtime\EncryptionLib\UnitTests
So not only did it whack my previous mappings but it put back an incorrect mapping. Is what I am trying to do not possible or is this just a bug? If it's not clear what I am trying to do let me explain it. I am trying to mimic the "parallel universe" model of branching found in clear case where I can have a private branch that appears in the same location as the branch source but just on my machine. That means my build scripts don't have to do anything special since the code in my private branch is located in the same directories in my workspace as their non-branched counterparts. I thought I could do this with path space branching with some clever use of cloaking and mapping.
One thing to note is that you can't have a folder cloaked if a parent of that folder isn't mapped. Therefore, if you actually do have $/Foo/Src/Runtime/EncryptionLib/EncryptionLib mapped rather than just $/Foo/Src/Runtime/EncryptionLib, you should have received an error when trying to cloak the UnitTest directory (if things are working as expected, of course).
In terms of where the odd cloaking behavior comes in, though, I'd like to try to reproduce the problem locally to get a better handle on it. Are you using the "Manage Workspaces" dialog to edit your current workspaces or are you using the command line "h workspace" command? Are you trying to set all the mappings at once or in sequence, saving the workspace state between?
Thanks!
It seems to work in the more recent builds, though I'll keep a sharp eye out for it. Could you try performing the mapping and cloaking in a new workspace to see if it happens there, too? Thanks for passing the issue along!
Yeah I'll try that. I should have mentioned that I had another line in my mappings config. The first line, which I didn't mention was:
active $/Foo C:\Projects\Foo
I would have thought that having this top level dir mapped would have been enough to allow me to cloak a directory several levels down. I hope it is not the case that you must map the cloaked directory's immediate parent directory.
I figured how to make this work from the command line. First you remap the "normal" project to a dummy location:
active $/Foo/Src/Runtime/EncryptionLib/UnitTests
C:\Temp\Devnull
Then you map in the branched folder:
active $/Foo/Branches/Developer/hillr/Exp_UnitTests
C:\Projects\Foo\Src\Runtime\EncryptionLib\UnitTests
This seems to work pretty good from the command line but confuses VS pretty good. Within the Source Control Explorer, looking at the Properties on UnitTests insists the repository location is $/Foo/Src/Runtime/EncryptionLib/UnitTest. However at the command, executing h.exe properties indicates correctly that the location is $/Foo/Branches/Developer/hillr/Exp_UnitTests/UnitTests. Also, when you load the solution somehow VS knows what you've done and wants to remap the repository folder pointing to c:\Temp\Devnull back into what it thinks the "correct" location is which of course is occuppied by the branched version. Figures. Anytime you try to do something "advanced" WRT to building your SW, VS gets in your way. Here I was hoping that MSBUILD was going to solve all these issues. Unfortunately it seems that the SCCI API in VS 2005 is just as crappy as ever. Yes, I'm a bit frustrated. :-(
Ah- I see where you're coming from.
I think the main issue here is that Source Control Explorer is actually a window into the server rather than a reflection of what data you have stored/mapped locally. It will grey out items that you don't have locally (either because they're not mapped or you haven't gotten latest), though it still shows them with their server paths. Hence, the folder named "UnitTests" is still the server item listed despite the remapping. What the remapping gives you the power to do is have a common script which says "run items from this relative path" and then pull from your alternative test branch rather than the original.
