The complexity of XML places demands on tools to work intelligently in order to preserve the essential structure of the original document and also represent the changes. This paper discusses the different varieties of merge for XML.
Merging multiple derivatives of a single ancestor (concurrent merge) may be the most obvious application, but there is also a need for a sequential merge when a document has been passed around between two or more authors in a sequential manner. Another important, and perhaps less well understood, application is ‘graft’, where the changes between two documents or data sets are applied to a third, different (though similar) document or data set.
There are of course similarities between these applications, but gaining an understanding of how they differ and where each is appropriate is necessary to make best use of automated processing of XML.
Branch and merge may be a software developer’s dream, but using this technique with structured documents can turn into a nightmare. The merge process is so often a manual one: cut and paste and get frustrated. Can structured XML merge turn the nightmare back into a dream?
Software developers are familiar with merge, e.g., pulling together changes from one branch into another in a version control system. Graft is a more selective process, pulling changes from selected commits onto another branch. These two processes are often implemented in the same way, but there are important differences between the two that needs addressing.
It’s common to have data in two files that we need to merge together, two different people or two different processes have made changes. Does it matter who or what has made this change? This question might help to decide whether you need a 2-way or 3-way merge.
Sign up to the DeltaXML newsletter to get the latest on DeltaXML and other company news.
WHERE CHANGE MATTERS
From ISO Quality Services Ltd.
