Mercurial Friendly Data Storage

[Michael Diamond]

Hello all,

I'm exploring the feasibility of a project that, at its heart, would be a
data storage system with changes tracked by Mercurial (and/or other VCSs,
but I know and like Mercurial best).  The catch is, I would like to be able
to easily look through the history of a file and determine the change
history of the data contents.  For instance, if I used XML and a file
contained a line "<name>Michael Diamond</name>" and it was changed from
"<name>Mikahl Dimoond</name>" I want my program to be able to identify what
changed was the <name> tag, just from the change diff.

And so my question is, what are your thoughts on the best way to store this
data to make Mercurial's job easiest?

What immediately springs to mind is either XML or JSON, but I'd be open to
other suggestions.  My concern is the cases where the file diff identifies a
better/different description of the change than what literally was changed.
 I see this most often when removing or inserting blocks of code and
Mercurial identifies a different bracket as the line that was "changed".  Of
course this usually isn't a problem, but it would make things harder if I
couldn't trust that the recorded change was what was actually changed.

Here's a constructed example of what I mean if it's not clear:

I have a portion of an XML file structured like so:
  <nicknames>
    <nickname>
      Mike
    </nickname>
  </nickname>

I add a new nickname, and Mercurial marks the +'ed lines as inserted:
      Mike
+    </nickname>
+    <nickname>
+      Diamond
    </nickname>

Obviously still correct, but it's no longer clear (to a program at least)
which value was inserted.

So, any thoughts on the best format to store data for programs to see
changes in without having problems like what I describe above?

Thanks for your help,

Michael Diamond
dimo414 at gmail.com
www.DigitalGemstones.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110119/8185b3b5/attachment.htm>