How to branch a single Class Library for a minor change (2.0 to 2.1) without branching the entire solution

Solution

The question is below the solution. Going off of what Scott Bruns suggested that branching by version might be our problem, I decided to thoroughly read through the Team Foundation Server 2010 documentation, as well as the Microsoft Patterns and Practices. The resources used are as follows:

Chapter 5 - Defining Your Branching and Merging Strategy http://msdn.microsoft.com/en-us/library/bb668955.aspx

I have chosen to utilize the following structure.

TeamCollection
    TeamProject
        Development
            Feature A
            Feature B
        Main
            TeamApplication
                Code
                    Project1
                    Project2
                    Project3
            开发者_Python百科        MyClassLibrary
                Documents
        Releases
            1.0
            2.0
            2.1

The understanding of this is quite simple. The main code base is in Main and contains the code base in its entirety, but not multiple copies or multiple versions. Furthermore, if a feature needs developed a single project can be branched into the Development branch, instead of branching the entire solution. The result is that the change would be merged back into the main repository. This provides isolation so that when a feature is being developed, it does not break the main code base.

So, how this solves my issue of maintaining different builds, is that when a new build is released, this is the scenario when the solution in its entirety would be branched into Releases. So, essentially, releases contains a full copy of the source code for each release, which makes sense. So hotfixes, bugs, and maintenance can be provided for specific releases, and merged back into the Main repository once the fixes and changes are stable.

So in the end, the Main code base would essentially always be the latest stable build of the software, while development isolates features and untested code, and releases isolates your builds and allows post-release maintenance.

The other part of the problem that lead to the solution was thinking we needed to branch for just any type of change that is not a 'fix'. Understanding you should only branch when absolutely necessary, we would now be applying fixes, changes, and the like to existing code bases and merge, instead of creating entire new branches.

I hope I explained this well. I am still getting a feel for Team Foundation Server 2010 and learning this well. A lot of answers can be aquired by thoroughly reading through the MSDN docs, Patterns and Practices, and the like. Some of it is a bit hard to understand at first, but eventually you catch on.

Hope this helps anyone with a similar scenario. I am still sketchy about a good method of branching features, whether the entire code base from main should be branched or just single projects. Like if just a new section of a WinForm needed added, should be able to just branch the form file, but without a project you don't have a designer, so small things like this seem like an issue.

Question

I did some searching on version control branching here on SO in regards to branching structures, and strategies, but none of those questions or answers fit my specific scenario, so here we go.

My source control structure is as follows:

TeamCollection
    TeamProject
        Code
            1.0
                Project1
                Project2
                Project3
                MyClassLibrary
            1.1
                Project1
                Project2
                Project3
                MyClassLibrary
            2.0
                Project1
                Project2
                Project3
                MyClassLibrary
            ...

The usual method I use for branching is to just branch the entire version directory. Say I want to make a new feature from version 2.0, I would branch the entire 2.0 folder to 2.1.

The problem I have encountered with this approach now, is that this project is 444mb in size, so with my current method of branching each version is 444mb and utilizes a lot of disk space. The other issue is its not necessary to create duplicates of all the files that do not need changed.

In the project, I have a single Class Library that I would like to branch from 2.0 to 2.1. I need to make just a small change to the library, but would like to separate this change from the 2.0 code base. The issue I am having is understanding how I should proceed to branch this.

If I branch as follows:

TeamCollection
    TeamProject
        Code
            2.0
                Project1
                Project2
                Project3
                MyClassLibrary
            2.1
                MyClassLibrary

I am trying to understand how I would then build a release of the entire product, but that would include version 2.1 of the class library if it is isolated from the other projects. I don't necessarily want the 2.0 code base to be changed to reference the 2.1 Class Library, because 2.1 should not be part of 2.0.

My other approach thought was to do:

TeamCollection
    TeamProject
        Code
            2.0
                Project1
                Project2
                Project3
                MyClassLibrary
                MyClassLibrary-2.1 (following the default suggestion of TFS Explorer)

This, makes some sense as the 2.1 branch is a subset of the code base 2.0 because it is a minor feature change, but this also creates an extremely messy file system hierarchy for large projects, and again, I am trying to understand how I would build version 2.1 of the entire project, without changing references in version 2.0. Again, 2.1 should be a separate build from 2.0.

My only solution is again to just branch the entire project, but I am trying to find professional help for this since the project is becoming large in size and branching all 444mb should not be necessary.

I would like to use the first option I suggested where I have 2.1/MyClassLibrary, but I would really need help understanding how I would be creating a build of the whole product with only the single project in the 2.1 directory.

Branching by version might be your basic problem.

Why are you required to work on different versions of an app in different folders? Do you really need to work on multiple versions of the code at the same time?

In our environment I would just get version 2.0 (or 2.1, etc) into the same folder structure (not at the same time of course). I would not need an additional 444mb of disk space.

Of course, your environment/branching choices may be very different.

Since Team Foundation Server does keep track of your local state on the server, you can use this to do some cool tricks - for example, using the poorly advertised /remap flag to tf get will let you switch to a different branch and only download the differences.

For example, let's say you're working in in version 2.0 and you have $/TeamProject/Code/2.0 mapped to C:\Work\Code. If you were to delete the working folder mapping for $/TeamProject/Code/2.0 and then map $/TeamProject/Code/2.1 to C:\Work\Code, you could then run tf get /remap and it would download only the differences between the branches.