Which Version Type to choose when Reverting Back/Forth in Code Versions? +TFS VS2010

My one and only coworker left a couple weeks ago, and I now have to Merge everything together creating a baseline work environment for my new developer and I. My previous coworker had done most of the management related to our Team Foundation Server.

My current structure consists of 4 Branches and a Bugs Branch. Branch A, and Branch B were our separate Development Branches, which were branched off of a Central Dev Branch (Branch C). The Central Dev Branch (Branch C) was derived from the Main Branch (Branch D). The Bugs branch shouldn't affect my problem so it shall remain unnamed.

I made some mistakes a while ago when trying to Merge everything together so therefore I've reverted to working versions of Branch A, Branch B, and Branch C.

Now that I've gotten working versions of Branch A, B and C I want to begin merging Branch A/B into C. I figure since I'm technically not working with the newest code, an开发者_运维问答d since I've reverted back to older versions that I may have to change the "Version Type" to something other than "Latest Version".

Should I be changing the Version type, or should I leave it as Latest Version and be on my way with Merging?

As I read the question the branch structure looks something like the following:

D (Main) 
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs

Quick terms (so I can use short notation):

• FI = Forward Integration (from Parent branch to a child branch)
• RI = Reverse Integration (from a child branch to it's parent branch)
• Branch C is the parent of branch A and branch B. A and B are children of C.

From initial question it sounds like the following state exists:

1. A and B both have changes that have not been RI'd to C.
2. You reverted previous merge attempts in C, B, and A.
3. (?) you committed the rollback in each branch (using tf.exe rollback ...) so when you "get latest" from each branch you have your working versions rather than the failed merge versions.

Here's my recommendation:

1. rollback to stable versions of A, B, and C (if you haven't already).
2. C->A, test, A->C, verify OK.
3. C->B, test, B->C, verify OK.

Details:

1. tf rollback to working version of A, B, and C (if you haven't done so already)

2. FI from C->A (C to A)

   • resolve all conflicts you can
   • create a shelveset for your
     pending merge
   • Now test in A
     until you are confident the merge was successful and you've got all of C working with all of A.
   • Commit the merge change to A.

3. RI from A to C,

4. Repeat steps 2 and 3 going from C->B, then B->C

TIP: "A" can be whichever developer branch has either the easiest or most important changes.

* If you decide not to commit the change to rollback to your earlier "stable" version then you probably need to use the Version type option... but if all three branches have changes needing rollback then you at least need to rollback c, then merge previous version of A. I'd personally prefer starting with all 3 branches having their latest be the working versions that you want to proceed with. (Merges are already tricky enough without having to merge to a specific changeset).

The scenario you described is very common, but is not optimal. If both A and B have been making frequent merges to C (after doing FI and testing each time) then your merge task will be much smaller.

MOVING FORWARD

I a couple recommendations that may reduce your future merge pains.

1. For daily work developers can use TFS shelvesets for their pending changes, then check directly into a common dev branch. Full branch is only needed if you require isolation (such as working on conflicting changes at same time OR multiple developers working on a breaking change)
2. Create a child branch from the common Developer branch only when you need isolation from other developer changes. For example, if you are implementing a breaking change that requires both devs to work on you can make a "feature" branch, one or both devs can work on the feature without destabilizing the developer branch, then merge back to Dev branch as soon as feature is stable.
3. FI Merge from parent to children often! Otherwise merges become very difficult to reconcile.

You may have too many branches for the size of your team (unless you have parallel features that should not exist side-by-side). Sanity decreases with number of branches you are away from Main. I'd have all developers work out of single Dev branch (C) then make a short-lived feature branch only when needed (then close the branch as soon as feature is stable enough to merge to Dev branch.

The TFS Branching Guide is a good resource for pretty branching pattern pictures and lots of guidance including different patterns that may better suite your needs going forward.

Enjoy! -Zephan

If A and B are development branches (by that I mean a branch where new code / features is added separately to the main development) created off C and they have reached the end of their life then they need to be re-integrated back into C. Merging the latest version of A or B into C is the right thing to do.