Version Control Guidance – Frequently Asked Questions

  • Article

Continuing from Version Control Guidance – Alternative Branching Strategies we discuss frequently asked questions in categories: Branching Strategies, Branching Operations, Branching Security, TFVC Gems, and Git Gems.

Frequently Asked Questions (FAQs)

Branching Strategies

What are the differences between folders and branches?

Why have we changed the strategy names?

  • We listened to the way engineering and users were talking about branching in casual and technical discussions. Our decision was to introduce strategy names that are meaningful and which you can visualize in your mind.
  • For example, visualize a basic branch plan. Now repeat the exercise, visualize a development, then a release, and finally a development and release isolation strategy. Which was easier to visualize?

Branching Operations

Are work items a part of the branching/merging model?

  • No, work items exist at a logical level that is distinct from that of the source control repository. When you perform a branch operation, you will not: duplicate the work items, carry over work item history, or update work item links.
  • For more information see: Copy a Work Item.

Can source code be branched across team projects?

  • Yes, you can but we do not recommend it unless two teams must share source and cannot share a common process.

How should we handle bugs over branches?

  • Branching of source code has no impact on work items, including bugs.
  • Consider who is responsible for the code and the bugs, whether responsibility and ownership moves (copied) the code or if bugs are resolved as part of the merge process.
  • For more information, see Copy a Work Item and Create or Delete Relationships Between Work Items.

Is there a preferred "Branch from version" value when creating a branch?

When creating a branch, there are five options available from which to choose the source.

  • Labels and workspaces do not usually refer a point in time but rather to a collection of files grouped together by the user.
  • Date, Latest Version or Changeset usually refer to a point in time and address the needs of larger teams.
    For example, for bug resolution knowing when the break occurred is a point in time (date) to consider. When moving to another sprint or iteration the Latest Version or Changeset may be the best fit.

Can you delete branches?

  • Yes. You need to understand your branching hierarchy and aware of future implications before deleting a branch. By deleting a branch, you are potentially removing a parent or child relationship, introducing the need for baseless merging.
  • For example, the diagram on the left allows changes to propagate from A -> B, B -> C and vice versa through the branch hierarchy. If you delete the branch B (see image on the right), you can only get changes from A -> C and C -> A using a baseless merge.

BH_1
Figure 14 - A -> B -> C branch hierarchy

What is required to consolidate or transition branches?

  • Before considering, a consolidation or transitioning of branches ask the following questions:
    • What are the predominant reasons for considering this action?
    • What are the benefits of this action?
    • What are the benefits for remaining with the status quo?
    • What are the risks of consolidation?
    • What resources will be required to complete a consolidation?
    • What is the exit plan?
    • What effects will this have on future development?
    • How will you incorporate any existing best practices?
    • Do we need to keep history and associated work items with the source?
  • Once you have decided on the answers to these questions, you will determine your next steps based on whether you wish to consolidate your branches or transition into a new environment. Transitioning to a new branch may be the easier of the two options. You can essentially lock off your existing branches and have everyone work in the new environment from the designated start point. This is most appropriate when applications that have been created and maintained by teams that were previously separate and do not have anything in common, other than they are now all products of a combined entity.
  • For consolidating branches, you will have to review your existing branches and determine what must be included. Once you have made those decisions, you will need to create a new mainline and proceed to migrate each designated branch. Along each step, you should verify that each migrated branch does not break the new mainline. If possible, do this in a sandbox environment prior to attempting in a production environment.
  • For more information, see Branch Folders and Files and Merge Folders and Files.

What is the “Re-parent Branch” function and when should you use it?

  • Re-parent Branch is a feature that you can use to establish a parent-child relationship between baseless merged branches (i.e. branches with no existing merge relationship) as well as to alter existing branches' parent-child relationships in a branch hierarchy.
  • However, to "reverse" an existing parent-child relationship, you need to disconnect the child branch from the parent branch using the "No parent" option, and then re-parent the former parent branch to the former child branch.
  • Refer to Branch Re-parenting for more information.

When should you use Labels?

  • We recommend labels in cases where you need a snapshot of source for future reference and or use and where the mutability of labels is not an issue.

Branching Security

Can a branch be truly immutable?

  • Can you lock your house and guarantee that no one can access? The answer is likely to be “no”.
  • While we can lock-down a branch with permissions, the “truly immutable” depends on your security architecture and enforcement thereof.

How do I manage permissions across branches for my team?

  • You should carefully evaluate how you manage access and permissions to source control. Taking the time to evaluate the levels of access that you need across roles and defining a roles and responsibilities matrix can provide you with a consistent and security focused solution. Consider using secure groups, based on Active Directory, since TFS can refresh automatically. Remember to include those people from outside your immediate teams who might also need access, such as IT Ops or Support. You may also need to take into consideration any corporate security or governance policies that apply.
  • Refer to Securing Team Foundation Server for more information.

TFVC Gems

What are the disadvantages of cherry picking changes?

  • Cherry picking means that you select only certain files to merge back to main branch. However, suppose another developer had to change more files than you are aware of. Because you did not execute a full merge, you left those files behind. Now your target source is “broken,” might not even build correctly and you will probably spend hours trying to discover what went wrong
  • A cherry picked changeset can fall in the middle of a future merge range resulting in remerge of that changeset. This can result in merge conflicts.
  • With more complex projects, cherry picking is more likely to cause problems such as bugs that you have fixed but then appear again in new builds, or broken builds due to incorrect file versions.

What is baseless merge and how does it compare to regular merge?

  • A baseless merge allows merging two folders that do not already have merge relationship. Once you perform baseless merge, you can then perform ordinary merges between the branches (as if the two branches had a normal merge relationship between them).

What is the maximum file length supported by TFS?

  • TFS currently supports up to 260 characters in any client and 400 on the server. Examples of paths are below:
    • Client: c:\code\src\...
    • Server: $/TP/SomeFolder/Code/Src…

Git Gems

Where can you find references to information we encountered while working with these exciting version control systems?

Please send candid feedback!

image

We need your candid feedback. Here are some ways to connect with us:

  • Add a comment below.
  • Contact us on our blog.

References

A special thank you to everyone who laid the foundation this and ither version control guidance: Anil Chandr Lingam, Bijan Javidi, Bill Heys, Bob Jacobs, Brian Minisi, Clementino de Mendonca, Daniel Manson, Jahangeer Mohammed, James Pickell, Jansson Lennart, Jelle Druyts, Jens Suessmeyer, Krithika Sambamoorthy, Lennart Jansson, Mathias Olausson, Matt Velloso, Matthew Mitrik, Michael Fourie, Micheal Learned, Neno Loje, Oliver Hilgers, Sin Min Lee, Stefan Mieth, Taavi Koosaar, Tony Whitter, Willy-Peter Schaub, and the ALM Community.