views:

86

answers:

1

I know .xcdatamodel is actually a directory with two files (elements and layout).

I know the two files are binary plists, and can convert them to XML plists with plutil -convert xml1 (while relying on this may be "unwise", it's perfectly fine for development: I expect that the build tools will compile/optimise/whatever when putting them on device, and assuming Xcode doesn't lose the ability to read old files, I can always convert them back to binary1).

My two problems:

  • Xcode modifies both files if you so much as move an entity (I would've expected that to just change layout), which is entirely unhelpful with multiple developers.
  • There appears to be no easy way to merge changes (even the XML plist format is an NSKeyedArchiver-serialized object graph, so a textual merge wouldn't work).
  • There appears to be no easy way to see what's changed (maybe I could convert them both to XML and do a diff... ugh).

Has anyone found a solution to any of these? Can I force Xcode to save as XML plists, or force Subversion to convert them to XML plists on commit? Is the diff even vaguely sensible? Is there an external tool that performs an .xcdatamodel diff?

EDIT: SCM-based locking doesn't really solve the problem any more than saying "I'm about to edit X"; the danger is that someone forgets to lock, makes a change, updates, and everything breaks. The svn:needs-lock property ought to work, but unfortunately Xcode doesn't respect chmod -w on elements or layout (an unwritable .xcdatamodel doesn't work either, even though Xcode shows the lock icon, and svn additionally fails).

A: 

I don't think this is possible. While tracking down a corrupt file several years ago I noticed the model files seem to change an inordinate amount of text structure for minor logical changes. It doesn't seem to be like code but instead the data structure gets oddly moved around. This might be the result of serializing nested NSSets which have no fixed order.

I think your best bet is locking the data model and only allowing one check out at a time. Frankly, I would be very nervous about merging any XML files in an old school manner.

TechZen
NSSets are probably saved in hashtable order. It's possible to make it vaguely consistent (use a better hash and take the high order bits for the hashtable index), but alas, it's far more common to use bad-hash-mod-a-large-prime. It also doesn't work for sets-of-sets...
tc.
Don't take that as gospel, its just a guess from what I remember.
TechZen