I can’t create a new folder in TFS Sourcecontrol

August 25, 2008 at 9:02 am 2 comments

Recently, I started working on a project that uses TFS, which I previously have not worked with before. After using it for a few weeks, we had to branch and that’s when it gets interesting. TFS uses location based branching. The branch is an actual new location in the source control. Not knowing this, we created a directory structure like this:


Ideally, the client and solution should be both grouped under a single folder so that we can just branch the folder and get something like the following


What I want to do is to move the client and server solution to Main, so I can branch from Main. I attempted to go to the MyProject, right-click on the right  panel in Source Control Explorer and select New Folder, but it was grayed out even though I have admin permission.


I had previously created the MyClient and MyServer project by adding the solution to TFS. As a result, I ended up with a workspace mapping from MyProject/MyClient and MyProject/MyServer. In order to create the new folders in MyProject, I need to add a folder to MyProject.

Unless you map a TFS folder to a physical location on your drive in the workspace, you canot add a folder in that directory. It’s actually fairly obvious in hind site, but it’s not immediately obvious the first time.


Entry filed under: TFS, visual studio.

Tips on installing Picasa Linux 2.7 on Linux Microsoft MOSS 2007 / WSS 3.0 Deployment Issues

2 Comments Add your own

  • 1. Dave Ziffer  |  January 4, 2011 at 10:32 pm

    Actually this answer doesn’t make any sense to me either in foresight or hindsight. Why does the Source Control Explorer force these seemingly useless restrictions upon us? Not only does it make no sense, but it’s counterintuitive. I would expect that the Source Control Explorer would be more inclined to let me rearrange my source structure when I DON’T have my source control tree mapped to any physical files. In that case, the explorer would not have to bother mapping all of my changes into the file system (incurring the possibility of failures due to file locks, uncoordinated file system changes, etc.).

    It seems to me that a far more rational way of doing source control editing would be:

    1. Require that I check in everything (so we don’t lose changes from the file system).

    2. Unmap everything that’s going to be modified (so we don’t need to track the source control changes in the now-superfluous file system that might not even tolerate being rearranged for reasons listed above).

    3. After making all changes, remap the source control folder(s) to the file system, recreating the file system in the new format without having had to force it through all the rearrangements.

    So does anyone have any idea why the Source Control Explorer seems to have it backwards, requiring that we do things in a way that would seem to involve the most maintenance and highest risk of failure?

  • 2. progressive car insurance  |  September 4, 2017 at 5:32 pm

    http://gettodayinsurance.org/ – cheap car
    progressive car insurance
    cheap car insurance


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


August 2008
« Jul   Sep »

Most Recent Posts

%d bloggers like this: