CODEWITHSUNDEEP
version-controlbranchperforce
Brian Mueller
Brian Mueller

Reputation: 171

Perforce and Feature Branching

At our company we use Perforce for our source control and version management. Currently we implement feature branching with the following "tree"

  Hotfix01 - Hotfix branch
  Hotfix02 - Hotfix branch
  HotfixNN - Hotfix branch
Main (continuous trunk)      
  RC - Release Candidate branch (next release)
    Working01 - Working branch, feature branch.
    Working02 - Working branch, feature branch.
    Working03 - Working branch, feature branch.
    WorkingNN - Working branch, feature branch.

We setup the branches ahead of time. Not that this really matters. Branches off RC are feature branches. Right now we have >50 developers, Analysts and QA team members that are working individually or as a team on various projects, defect fixes, etc. When work comes in you find a free branch (we track that separately), claim that branch (e.g. Working56), do a force merge/sync from RC to that branch (to make sure it's exactly what's in RC at that moment), do your work (code, peer review, QA) while continuously merging any changes from RC to your working branch (at least once per day, perhaps more often as needed) and when you are done you copy the changes up to RC.

This works, but it means we have (at this time) 300 working branches to manage. We would like to implement feature branching in a more sane way where we would use branch mapping and such to create a branch as needed, named after what it's for and then once we merge it back to RC we want it to no longer show up in the depot forever (at least, not for every developer). Basically we want to see only those branches with active development as feature branches, hiding branches we are done with.

What is the best practice? Can this be done with perforce using either branches or streams? Are we missing something with Branch specifications that would allow this? Should we just not worry and allow thousands or tens of thousands of feature branches to pile up in the depot view under RC? Is the way we are doing it now the best we can hope for?

We've been using Perforce for 10 years and this is still a question that haunts us daily.

Upvotes: 2

Views: 603

Answers (1)

Samwise
Samwise

Reputation: 71562

Task streams are designed for this.

https://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html

Create the task stream, do your work in it, merge/copy back to the parent, then unload the task stream.

Common task stream gotchas:

  1. Do not try to reuse or reparent them. One stream per task! If you try to reuse task streams their beneficial features mostly don't work but you still get all of the limitations.
  2. The modified depot files live on after the task stream is unloaded. Adjust your mental model to use the list of streams as the source of truth for which streams are active, not the folders in the depot tree.

If you can handle those, task streams are hugely useful.

Upvotes: 2

Related Questions