Hello Tye,
So, the difficulty on merging these files is that either a large part of these files (x.orm) or all (x.dcil.xml, x.ddil.xml) are generated, which makes merging difficult. The generated sections of .orm files also have non-stable identifiers, which makes them exceedingly difficult to merge.
It doesn't really matter if the last two files merge cleanly or not. You can simply right-click the .orm file in the Solution Explorer and choose 'Run custom tool' to recreate them from scratch (or simply open and save the .orm file in the ide). The trick is getting the .orm file merged cleanly and in a consistent state.
The stable (non-generated) sections of the .orm file are all the pieces in orm:ORMModel and ormDiagram:ORMDiagram elements in the XML. If these merge cleanly then the ORM model itself should be OK, which leaves the generated pieces to deal with. Of these, the oialtocdb:MappingCustomization and orm:GenerationState sections should also be stable. Pretty much everything else is generated.
For a clean mapping you can do the following. However, this is guaranteed to leave the relational view with unresolved shapes.
- oial:model: delete contents, leave element
- rcd:Schema: delete contents, leave element
- rvw:RelationalDiagram: leave element, delete contents
- ormtooial:Bridge: leave AbstractionModelIsForORMModel, delete all other elements
- oialtocdb:Bridge: leave SchemaIsForAbstractionModel, delete all other elements
- In orm:GenerationSettings you'll see three attributes with 'AlgorithmVersion' in the name. Drop the last digit in the version by one on each of these (1.009 -> 1.008, 1.004 ->1.003, 1.014->1.013). This forces the algorithms to regenerate everything on a file reload.
This isn't a great answer, especially if you care about the relational view layout (which you may on on a large model). Hand merging the bridge elements would be painful because duplicates will likely throw on model load. If you have no customizations (name generator settings, subtype mapping customization, etc.) then you just pick one model to keep the generated elements for and tweak the algorithm version. Reload the document, save to regenerate, and your other files (dcil, ddil) will regenerate correctly.
There are other approaches here. For example, if you know which elements have been modified or added in the file you're merging in you can simply rename one file, open it, and drag the new/updated elements from one file to the other. This may actually be easier than the above process.
I wish I had a better answer here. I know these are very difficult merges. I generally take the last approach (look at the XML diff, find the changed/new/delete elements in the target file, and drag/drop or hand apply the changes.) Obviously, if you can get the non-master branched merged or rebased on master before pushing up you'll be in much better shape because you'll be able to fast-forward the pull into master.
-Matt