We use git for source control. The data.plist files used to be in XML format, but somewhere along the way they became binary files. This makes merging impossible, is there some way to specify the format that the data gets saved in?
Not saying this is the answer. But a quick test. I was able to convert the plist from binary to xml.
Using terminal.app
plutil -convert xml1 /Users/userName/Documents/Hype/Example.hype/data.plist
This converted it to a plain text xml ( in place).
Opening the project after worked with out any issues. Which is what I would expect but @jonathan would know better.
Here is a Automator.app workflow.
You can drop it into ~/Library/Services
Which will allow you to select a project file and convert it. ( using right click on the file to get the services contextual menu )
On completion you should see a Notification telling you what the file type now is.
Hype Convert Data_Plist.workflow.zip (225.5 KB)
1 Like
The format change was done because Apple introduced two bugs in XML plists in macOS 11.3 where it would take 200x longer to write the file and another where it could hypothetically fail to write the file, leading to complete document loss. The first was fixed in macOS 11.5, but the data loss issue has only been fixed in the upcoming macOS 12.
Since binary plists do not encounter these issues, we changed the format to this. It is a bit of a pain in multiple respect that it is no longer plain text, but an added benefit is that file sizes are much smaller 
.
Hype can continue to read XML plists just fine, so if you manually do a conversion like what @MarkHunte showed, it should be okay. Hype will just keep writing out binary plists, so you'd need to keep doing this. The manual conversion tools may be subject to the same bugs, so watch out for that.
That said.... in general, I wouldn't count on merging plist files since they are structured XML and git's merge tools are based on text lines. You could easily wind up with a broken file. (I deal with this all the time with Xcode's project plist files!)
2 Likes
Thank you both @MarkHunte and @jonathan for your answers, that helps a lot! I'm going to play around with this, but sounds like I should be treading lightly with merging any way.
1 Like
I ran into this problem in my Hype Bundles project. I am running a similar command (see @MarkHunte post) to convert the PLIST since build 734 using a Python export script/bundle, as I like to read the PLIST as a data source in some cases. It is straightforward to query the PLIST in Python and doesn't require a reverse lookup if going the other route of parsing the JSON in the DocumentLoader Hype outputs.
There's also rare risks of it generating a valid XML plist but still being an improper merge if not checked very closely - in this case the document may open but data could be corrupted in ways that cause very bizarre issues in your document/the app. (Of course, we didn't change the format to help mitigate this, but just something to be aware of!)