In TFS is the direction of a branch's parent-child relationship important

Question

Is the direction of the parent-child relationship between branches important? Is parent/child just an abstract concept that identifies which was the source and which was the destination, or are there specific operations that can only be performed in one direction, therefore, making the direction of the relationship important?

Here is some background information to explain the reason for this question..

We have recently implemented a new branching strategy and decided to go for this simple set up:

Dev -------------------------------
          \
      Main >-----------------------
                  \
        Production >---------------

This seems to work for us, but all the recommendation guidance I read suggests that Main should be the root. So instead it should look like this:

      Dev  >-----------------------
          /
Main ------------------------------
                  \
        Production >---------------

This is pretty similar, but obviously the parent-child relationship between Main and Dev is reversed.

What problems would we be causing for ourselves if we keep Dev as the root with Main as a child of it? The only issue I can see is if we take a second Dev branch off of main.. It would have the opposite parent-child relationship to Main as the other Dev branch, but again I ask what significance does this have?

Thanks for looking, please let me know if you want any more information.

Answer 1

Short term: For the short term tell everyone to treat DEV is a child of MAIN even though it looks like a parent in TFS.

NOTE: You can reparent the DEV branch in TFS... and probably should if you think the conceptual terminology and process risk for your specific team will be greater than risk of correcting the TFS branch structure.

ADDITIONAL THOUGHTS

I'll echo that branch direction is technically unimportant to TFS. But be very careful about the humans who are much more easy to get mixed up. It is important is that every single person doing merges between branches (or creating new branches) clearly understands the branch hierarchy and follows your group's official terminology and branch/merge process.

MAIN (aka Root or Trunk or Ancestor branch): You can arbitrarily designate any branch to be the "Main", "root", "trunk", etc. branch. Remember these terms are commonly used interchangeably, especially for new dev hired from a different company. As long as everyone doing merges and branches knows that you treat the MAIN branch as the team's root/trunk branch then you are OK. If you casually ask someone to make a new release off the root branch and they decide root=DEV branch then you have a problem (even if your branching diagram clearly supports the idea that the "root" branch is DEV).

MERGE DIRECTIONS: FI (Forward Integrate from parent to child) and RI (Reverse Integrate from child to parent) are the most common terms used to describe direction of merges. I subscribe to the FIRI ("Fiery") merge pattern to ensure all changes in the parent are FI merged to child (resolving all conflicts and tested as needed) before RI merge to parent. This really helps keeps parent branch more stable than children. This idea matters for your question because currently FI implies from DEV (parent) to MAIN (child). If you and all branch/merge people can ALWAYS pretend that DEV is a child branch then you can say "Did you do FI before merging to MAIN branch?". Likewise your Team's Branch/Merge guild can explicitly state "IMPORTANT: In this guide (and in general discussion) always treat DEV branch as a child of MAIN even if technically is the parent in TFS (as of 4/25/2012)." Then all statements can use standard terminology without constantly using reverse terminology when discussing DEV branch.

(If you already use other terminology in your team such as "merge up" and "merge down" that is ok... as long as everyone including new-hires clearly understand what these terms mean. (Also note "up" and "down" branches are drawn differently at different companies so this terminology can cause confusion.)

NEW BRANCHES: If your team decides to create a new DEV_FeatureX branch from MAIN then it will be a child branch. (TFS enforces each branch having only one parent... you currently can't be a child born from two mothers :-).) Likewise if you Branch By Release (now or later) these branches will be new children of the MAIN branch. Over time this will

Remember that computers make mistakes far FAR less often than humans. Enjoy! -Zephan

Answer 2

The direction does not matter for branches. A given branch can be "based" on another one, then creating a relationship but you can merge with the exact same benefits from either direction.

The only difference is somewhere else, and it's a big difference.

Let's take your first graph where Production is based from Main which is based from Dev:

• You'll be able to merge efficiently from Dev to Main, Main to Dev, Main to Prod and Prod to Main.
• BUT merging from Dev to Prod or Prod to Dev will be a real pain.

Why ? Because you benefit of Three Way Merge when the source and destination branches are directly related. If the source and destination branches are indirectly related (e.g. Dev and Prod), then TFS only will be able to make a two-way merge, which leads you to many many more conflicts.

If you want more info about three way merge, here's the wikipedia link

To sum up: Both graphs are the same in regard to TFS, it's all a matter of what branch model you choose.