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 Model, Option, Version, Rule, and 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 Price and Cost objects are hanging on the edges, each with their own set of properties (Price.Retail, Price.Calculated, etc.).

  • 2
    What kinds of objects are these? Jan 12, 2016 at 19:19
  • 1
    Simplest possible solution: Serialize your data to formatted XML or JSON and use git to handle the merge. If you want to do something smarter: develop a diff between business objects that makes sense to the users of your application.
    – Patrick
    Jan 12, 2016 at 20:18
  • Maybe it's just me, but I don't understand the situation. What is a "primary object" and their "representative children"? Are "Versions" and "Projects" the same thing or not? And most importantly, what is your current solution?
    – gardenhead
    Jan 12, 2016 at 20:44
  • @Patrick: I thought of that; I see ups and downs -- it's still under consideration.
    – J.D. Ray
    Jan 12, 2016 at 20:58

2 Answers 2


What you want to do is called a three-way merge.

Basically, you take the original before the branch, and the end result of the two branches. You take the differences between both branches and the original, and merge those diffs together.

How do you merge the diffs? That's the tricky part, but here are several projects which implement the algorithm for arbitrary javascript objects:

  1. https://github.com/dominictarr/xdiff
  2. https://github.com/rsms/js-object-merge
  3. https://github.com/falsecz/3-way-merge

You may find that you need to devise your own business-specific rules about how to merge. But I think you'll want to follow the same basic pattern of a three-way merge.

  • I'd be asking too much if I wanted a .NET implementation of one of these, wouldn't I?
    – J.D. Ray
    Jan 16, 2016 at 23:17
  • @J.D.Ray, yes. I don't use .NET, but these particular implementations make heavy use of javascript's dynamic nature to do what they do. I'm not sure such a generic library could exist for .NET. Jan 17, 2016 at 15:29

My thoughts:

  • You should implemented objects writeTo/readFrom in some human readable text format like csv, xml, json. Advantages
    • Can be maintained via texteditor
    • Support for textual find&replace
  • If you have (embedded) lists of (sub-) objects make shure that they are always in the same order (i.e. sorted by name). Advantages
    • Windiff will only show relevant changes.
  • instead of importing/exporting autogenerated database-keys use symbolic key-s since the database key may varay from system to system.

We use csv-files with these constraints to maintain our testdata via git for automated integration-tests. csv files can be easily edited via libre office. Microsoft Excel as csv editor is problematic because it interprets colums as dates, Numbers, ... which may ruin content when writing back to csv.

  • We don't want the users having a way to manipulate the data by hand (text editor), and there will be no importing and exporting between systems; at least not for this function. If SCM solutions are using rulesets to determine how to merge changes between complex file sets, I should be able to establish similar rule sets within the business logic layer of an application and have those rules execute. I'm after guidance on how to implement such a function and also how it might be designed (this change trumps that change because, even though it came in earlier, it has more priority because of...)
    – J.D. Ray
    Jan 13, 2016 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.