We're working on a project wherein the business users operate on a set of data that is periodically published. We've labeled the publishing milestones as
Versions, and, due to some business constraints, end up duplicating the data set for each Version that gets published.
During the work cycle, it often becomes prudent for one of the work groups to spin off a side project (which we've aptly named
Project), work on that set of data for some time, then blend their changes back into the parent Version, possibly waiting until two or more Versions have been published before their changes get blended back in.
I can see the lights coming on from here. "Ah ha!" you say, "That's the same thing that happens in [Git, SVN, TFS, etc.]; code branching and merging. Just do that."
Right, that's a perfect lead-in to my question: how does one implement branching and merging for business data that is spread across seven or so primary objects and their representative children? I understand clearly what I want to achieve, I just have no idea how to write the rules so that the developers can take it forward and implement successfully (I'm the solution architect for the project and a middling code writer). I tried researching it, but am only finding articles on which Git (or Svn or whatever) commands to run to get the desired results.
By the way, we're developing on .NET 4.5 and implementing Workflow Foundation and Entity Framework if that helps matters.
Per the question below, the "primary objects" are things like
Note. Each of those have child objects (a
Rule has a set of
Conditions), joining objects (
RuleVersion), and of course properties (
Option.Description, etc.). One of the system's primary function is to track cost and retail price, so
Cost objects are hanging on the edges, each with their own set of properties (