Removing main trunk in branch hierarchy and having just same level branches

Question

I have decided to branch my TFS solution into 4 branches. I originally had one VS solution that was under source control, called 'Development'. As the product grew I decided to create 3 branches for the three clients that use it. So I have:

1. Development
2. Development-Client1
3. Development-Client2
4. Development-Client3

I had a new change request for 'Development-Client2' and wrote the code and made the changes. When I checked the source files in I noticed that 'Development' is also taking these new changes into account.

What I expected to happen, when I branched 'Development', was that I would have 4 versions of the solution and I could merge changesets between them.

From my current set up, it appears that any changes I make in #2, #3 or #4 will be automatically added into #1.

Since the branching occurred recently I feel I am in a position to sort it out now. Does anyone know what I need to to to get 4 independent branches?

UPDATE

In my solution file I have 6 projects:

1. ASP.NET Web Site (running against localhost).
2. Console Application
3. Class Library (Business Logic)
4. Class Library (Data Access)
5. Class Library (Entities)
6. Class Library (Common Methods)

I have noticed that for my new features in 'Development-Client2' that the changes in projects 2-6 have not been added to the 'Development' branch or the 'Development-Client1' or 'Development-Client3' branches.

However, any changes I made to the 'ASP.NET Web Site (running against localhost)' in the 'Development-Client2' have been replicated into all branches.

UPDATE 2

What I think has happened, in the following order, is:

1. I had a solution called Development under source control (TFS)
2. I created a branch called Development-NewFeatureX
3. I branched Development-NewFeatureX 3 times, I was left with Development, Development-NewFeatureX, Development-Client1, Development-Client2, Development-Client3
4. I deleted the Development-NewFeatureX branch.
5. I made loads of changes to projects 1, 3, 4 and 5 under the Development-Client2 branch.
6. At this point, I realised that project 1's changes had been replicated across the other branches.

I have also noticed that in the Source Explorer part of TFS that the each of the branches' solution file is pointing at 'Development-NewFeatureX' for the project [ASP.NET Web Site (running against localhost)].

I have tried to check out the solution file and modify the path from:

..Development-NewFeatureX/ASPNETSITE

to:

..Development-ClientX/ASPNETSITE

However this is just not working and source control seems to be overwriting the solution file.

I think it is at the point that I concede defeat and try to start a new solution.

If any TFS gurus have any idea what I'm talking about please give me some advice

SUMMARY OF PROBLEM

• I have 4 branches.
• Any time I open the solution file of any of the branches the project: "ASP.NET Web Site (running against localhost)" it is not different. i.e. it's the same one. So if I make a change on this project in any branch it is across all of them.
• The mapped folder of this problematic project is the branch that I deleted previously.
• The structure of TFS seems correct with the branches/projects. It is only when I open the solution file that the ASP.NET site is always the same one.
• Please see screenshot.

Answer 1

Here is how i would lay out my Branching and Development strategy using your situation:

• Root
  • Development (Folder)
    • Main (Where the common base code lives)
    • Customer A (branch of main)
    • Customer B (branch of main)
    • Customer X (branch of main)
  • Release
    • Customer A (folder for stable dev Customer A)
      • 20110101 (branch by release date, or some other designation like version)
      • 20110301 (fix production bugs related to Customer A here)
    • Customer B
      • 20120210
    • Customer X
      • 20120101

On your local machine in IIS, setup a website with a different port for each customer and the Main branch on port 80. This way you can access all builds parralel without switching around.

This strategy will allow you to do general bug fixes or common features in Main and do an FI into Customer branches when needed. If needed you can do an RI into Main from Customer but you really shouldnt need to if you stick to the purpose of the branches.

This also allows you to keep a version of the code that was stable for future needs or bug fixing for each Customer.

I know this doesnt fix your problem but I hope it helps with the future layout of your projects.

Answer 2

In my experience VS always required handholding with websites from localhost.

Here's what always worked for me:

• Create web projects only like this: File -> New Project -> Web
• Always Specify the location of the project, i.e. w:\project\code\AppWebLocation
• Then you can in Project Properties -> Web -> Servers
  • use localhost/virtualDir - it will do the mapping for you
  • use VS Development Server - I hate it :-\
  • use IIS Express - localhost is better option I think.

I think what happened it your case: you have used File -> New Web Site project, it placed the project into solution file and then you connected that Web Site into your Client solution as it was in the same location. Since then TFS was picking his files from the same place for all clients. which is pita.

Answer 3

A few things to try.

Since you have 2010: have you tried tracking one of your changesets in the branch visualizer? Pick a specific changeset made in one of your grandchild branches that you think replicated itself back to the other branches and see where TFS thinks it went? If it's lit up in the other branches, with new changeset number(s), then that's indicative that a merge has occurred. Then you can locate the merge changeset and see how it came to be.

If no merges, then what about the history of specific files in your other branches, that you think got replicated in from elsewhere, and check their diffs to see where their changes came from?

Did you check your IIS/virtual directories settings? Is each branch pointing at a correct virtual directory?

How many local workspaces do you have set up and how are they configured? Multiple workspaces in TFS can cause confusion because the one you're looking at in Source Control Explorer may not be the same one you're seeing in Pending Changes window and this can cause checkins to go someplace other than where you intend.

Finally, I am curious - what's your reason for wanting the branches to be detached from their grandparent and from each other? I'm not clear on the benefit of/motive for deleting that parent branch and cutting them all off; doesn't TFS like to have those parent/child relationships preserved? Or is it clever enough to remember?