Branch from a DEV branch or branch from trunk?

Question

Back ground:

We are working out how we will control our SVN repository. We are trying to workout a system that works in our daily business process.

Our business is based around: - T-SQL script files - An in house scripting language - business and form data loaded via .csv files - We DO NOT "compile" code.

We have 4 developers that receive work orders to make changes to SQL or components commands, data load scripts, etc. The developer will then make a work order branch to holds their changes from either Trunk (clean production scripts) or a DEV branch (represents our DEV environment for the combined changes for all work orders), this is yet to be decided.

Our initial repository plan is something like:

Dev Branch (with all our recent changes) Stage Branch (where we merge the work orders that are about to go to production) Trunk (a pristine representation of production)

We often have several work orders ongoing at the same time. So we would have several active branches. It is somewhat common for the same file to be changed in multiple work orders at the same time.

This makes things complicated for tracking the work order changes that get postponed while waiting for user approval. Sometimes they are rejected and never go in! We risk unintentionally promoting code from these postponed work orders if we branch from DEV.

The following example illustrates the concern from branching from DEV:

• day X
  • 1 WO1 branch - gets file version 1 (from DEV)
  • 2 WO2 branch - gets file version 1 (from DEV)
  • 3 WO2 merge back to DEV - file version 2
  • 4 WO3 branch - gets file version 2 (from DEV)
  • 5 WO1 merge back to DEV - file version 3
  • 6 WO3 merge back to DEV - file version 4

Now we get approval to promote WO1 & WO3. WO2 is lagging behind but we must move the others into production.

Here is the glitch. How do I identify that WO3 has WO2 changes? The DIF will show changes but that is to be expected. We cannot install anything from WO2 as it would break our auditing requirements.

Ideally we need to extract out the WO2 changes rework WO3. Compounding the issue WO2 may need to be reworked depending on how long it lingers as well, I.E. later work orders change the file too. Unfortunately we will have this issue with any work order using this file as long as WO2 remains outstanding.

On the other side of the coin, If we branch from trunk we have some issues as well.

• We are missing all the changes from other recent work orders using the same file(s). So depending on how many changes have happen while we developed the work orders independently or the changes while we wait to promote a work order could result in some serious merging issues. Hypothetically, we could reduce that risk if we got the branch from DEV which has the most recent changes that are merged to DEV.
• Similarly the developers need to keep their databases and environments up to date as possible. But if we are pulling from trunk it may not have database schema changes made in ongoing work orders. Or dependent T-SQL scripts from ongoing work orders.

Basically we are debating the benefits or costs of branching our work order changes from trunk (production) or DEV (a repository of production plus recent development changes.)

With the above info in mid does anyone have any advice for which way to go?

Answer 1

1. You are victim of premature merges

2. You have seriously re-think about using BASE-branches: overlapping functionality, Trunk is slightly camouflaged tags...

   • Use single branch as real "mainline", which doesn't have other changesets, than mergesets from "WorkOrders" branches
   • Always create WO-branches from HEAD of "mainline"
   • Never merge unapproved WO-branches to mainline
   • Perform sync-merges from mainline to WIP WO-branches, if mainline changed during time of branch's lifetime