Re: Merging two XML files (with conflicts)

Replies are listed 'Best First'.
Re^2: Merging two XML files (with conflicts) by CountZero (Bishop) on Feb 07, 2012 at 10:47 UTC
I think you have hit a major problem here. Actually you can avoid changing/updating existing records, if you have a well established protocol for adding and deleting. Changing/updating then becomes a simple "delete this and add that" operation. But that is something which the "patch" file is ambiguous about. The way it is now, it can only be reliably used to add data, not to delete, nor change ("patch") existing data. What tells me that "patched text 1" should replace "text 1" and not simply be an additional `<NODED>` within `<NODEC name="1">`? CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Merging two XML files (with conflicts)
by CountZero (Bishop) on Feb 07, 2012 at 10:47 UTC

Actually you can avoid changing/updating existing records, if you have a well established protocol for adding and deleting.

Changing/updating then becomes a simple "delete this and add that" operation. But that is something which the "patch" file is ambiguous about. The way it is now, it can only be reliably used to add data, not to delete, nor change ("patch") existing data.

What tells me that "patched text 1" should replace "text 1" and not simply be an additional <NODED> within <NODEC name="1">?

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
[d/l]
[select]