1

**This question was downvoted and identified as a duplicate, even though the other proposed duplicate question is considerably different from my scenario. That problem is a question about how to merge already existing branches. My question is how to correctly/ideally change the project structure/add branches for an existing project with no branches. I even linked to another question that is exactly the same as mine, except I have additional questions that weren't answered in that one.

This is probably pretty basic, but I'm having a hell of a time trying to figure out the recommended approach for adding branching to an existing project in TFS2013 that has never used branching. This post is the same issue (for TFS2010), but the answer leaves some questions.

My specific scenario is that I've got an old project that has never had branches and wasn't setup for branching. From what I've read it appears as though starting with /main /dev and /releaseX /releaseY folders and converting them all to branches right off the bat is the recommended approach, but that ship sailed a long time ago. The company I'm working for needs to be able to maintain release branches for hotfixes for customers that have lots of different versions.

One recommendation was to simply to convert the top-level team project itself into a branch and treating that as the main branch. That seems fine, but I've also read that you can't create any branches inside of a branch, so how/where would I proceed to create the release branches?

The current structure looks like this, and the release folders are what I had in mind:

  • server\default collection
    • team project
      • ...all the project's files and folders
      • ReleaseBranches
        • Release 1
        • Release 2

So, do I have to create a "Main" folder, move all the project's files and folders into that, turn that into a branch, and then setup release branches at that level? Or is there some way to convert the root folder to a branch and have the release branches under it? Or do I have to create a separate project for each branch? Or, is it possible to not have a main branch and just create branches for releases (I recognize this probably isn't best - it would make merging more difficult)?

This is a very small team and I'd like to keep the changes as simple as possible, and make it as easy as possible for the team to merge bug fixes from the main to older releases. One other thought I have is how this might affect the CI build I've setup. If the branches exist under the project collection mixed in with the main code, then would checking in to a release branch trigger the CI build?

Community
  • 1
  • 1
Dave Novelli
  • 2,086
  • 4
  • 32
  • 42
  • I'm not sure why I'm getting downvoted?? – Dave Novelli Jul 06 '15 at 19:16
  • possible duplicate of [TFS Branching & Merging Strategies](http://stackoverflow.com/questions/5718669/tfs-branching-merging-strategies) – nschonni Jul 06 '15 at 21:40
  • It's not even close to being a duplicate of that question - that person already has branches and they're looking for guidance on merging. My question solely concerns how to modify my project/source structure so I can ADD branches to an existing project that's never had branches. I even linked to a "duplicate" of my question (in a different TFS version) and explained that there was more I wanted to understand than was answered in that question. – Dave Novelli Jul 06 '15 at 22:41
  • I up voted ,great question – Hakan Fıstık Dec 23 '15 at 16:55
  • I've no idea why you're being downvoted either. I'm in exactly the same situation. Did you manage to solve this in the end? – Pseudonymous Jan 22 '16 at 10:08
  • I kinda solved it - I just moved all the current code into a new main folder at the root level, then created a release branch folder from existing labels. The branches created from labels before this restructuring are lacking some of the merging functionality, but new branches after the restructuring are just fine – Dave Novelli Jan 22 '16 at 16:54

2 Answers2

2

If I were to setup branching based on the situation...

So, do I have to create a "Main" folder, move all the project's files and folders into that, turn that into a branch, and then setup release branches at that level?

Yes, this is probably the best start.

Or is there some way to convert the root folder to a branch and have the release branches under it?

I don't think you can create the Team Project to a branch, and if you could, you wouldn't want your releases in there.

Or do I have to create a separate project for each branch? Or, is it possible to not have a main branch and just create branches for releases (I recognize this probably isn't best - it would make merging more difficult)?

How did you create these "release branches"? Did you branch the folders?

This would leave your structure like this:

Team Project
 >Main
 >Release Branches
  >Rel1
  >Rel2

Depending one how you maintain your release branches now, I'd leave them as they are and keep "merging" changes into them as you are. If you really want, you could try and re-create them once a "Main" branch exists by using the branch from Changeset option in TFVC.

Going forward you will be able to branch each Release from Main when it shipped. You can also create feature branches from Main if you ever need to do some long running disruptive work.

DaveShaw
  • 52,123
  • 16
  • 112
  • 141
  • Thanks Dave. The current code has no releases branches, so it sounds like I'll just move all the existing code to a new main folder for the main branch, and create release branches off the existing labels. – Dave Novelli Jul 07 '15 at 03:29
2

I still think that this is a legitimate question, since I also ran into a similar problem. Here is what I did with my test project "BranchTesting" (and later with the productive project). The great point about it is, that it keeps your change history of all the files:

  1. Create a backup folder on your computer of the current version of your source. During the following steps, your file in the mapped folder will completly be wiped and overridden with each version which you want to write into the Release branches.
  2. Make sure that all your changes are checked in and that you have a changeset description or a label which identifies the newest version (eg "Newest Version").
  3. Create the 3 folders "Main", "Dev" and "Release" (or Main and Release if you don't want a Dev folder) in Source Control.
  4. In the Subfolder Release, create folders for each Release (e.g. 1.0.0 and 1.0.1 or however your release management works)
  5. Right click on the team project and checkin the folders.
  6. Right click on each of the Release folders (not the root "Release", just "1.0.0" etc) --> Branching and Merging --> Convert to Branch
  7. Add a description for the branch, keep "Recursively perform this conversion on all folders previously branched from this folder" checked and click "Convert". The folders are now displayed as branches. This doesn't need a checkin.
  8. Right click on your Team Project --> Advanced --> Get Specific Version
  9. Search for the changeset or label of Version 1.0.0 and make sure that "Overwrite writeable files that are not checked out" and "Overwrite all files even if the local version matches the specified version" are checked. This will delete all folders on the disk which you've previously created!
  10. Right click on the "Release" root and Get Latest Version. This downloads the folder and the subfolders to your computer.
  11. In Windows Explorer, navigate to the project folder and copy all downloaded elements (usually the sln file and the folder with the source code) to the subfolder Release/1.0.0
  12. Make sure that you see a split screen of the Source Control Explorer (VS) and your Windows Explorer. Now move the previously copied files via drag and drop into the Source Control Branch 1.0.0
  13. Right click on the Branch and checkin. Mark it as "Added Source to Release 1.0.0 Branch".
  14. Repeat steps 8-13 for all releases.
  15. When all Releases are done, right click on the newest release branch --> Branching and Merging --> Merge
  16. Select the Main Branch and perform a Baseless Merge. This guarantees, that your main branch gets the changeset history from the release.
  17. Optional, right click on the Main branch --> Branching and Merging --> Branch and select your Dev folder to create a Dev Branch

I went a bit further and created 2 subfolders in the Dev Folder to create 2 parallel Dev Branches, but that's up to you. Here's how it looked at the end: Project Structure

Here is the changeset history: Changeset History And here the history of the program file (from the test program): enter image description here

Edit: I realize that imgur doesn't keep images forever, therefore here with text:

Team Project
 > Dev
   > EligibilityEnhancement
     > BranchTesting
   > Ryan
     > BranchTesting
 > Main
   > BranchTesting
 > Release
   > 1.0.0
     > BranchTesting
   > 1.0.1
     > BranchTesting
Davatar
  • 160
  • 1
  • 14