Project versioning?

deck

Is there a way to save a spine project as multiple files, for example one file per animation, or having text files instead of binaries, in order to make versioning easier for big projects?

With a single binary file (the .spine) it is very difficult to do collaborative work on the same project, since it is not possible for two people to work on the same project at the same time and merge the result, even if they only edit different animations. Even on solo work, it is not possible to easily revert commits made from git for example, without having to painfully redo all the changes that were good.

Our animations are quite complex, and at a late stage it becomes scary to edit things knowing that errors might be very time consuming to fix, even with frequent commits.

Nate

There isn't a way to save a project file in pieces, sorry. It's true the project file can't be easily diff'ed. You could export to JSON and version that, as some people do.

deck wrote
With a single binary file (the .spine) it is very difficult to do collaborative work on the same project, since it is not possible for two people to work on the same project at the same time and merge the result, even if they only edit different animations.

FWIW, you can merge animations from a skeleton in one Spine project file into a skeleton in another (or the same) project file by using Import Project, Animation:
Import - Spine User Guide: Animation
It has some important limitations, described there. It can be used to have a master project file, distribute copies to animators, they create animations (keeping in mind the limitations), then usually give their copies to a single person who imports the animations into the master project.

The master project can be added to and animation imports from older copies will still work. However, if the master project has things removed, then animation imports from older copies may partially fail. For example, if a slot no longer exists and that slot was keyed. Spine still imports as much as possible in those cases, so the animation can be fixed up.

deck

Alright that's better than nothing for the animations.
I assume you loose a bunch of data about the Spine project by exporting to JSON and importing that in Spine? Or does the output "Nonennential data" option saves everything (bones icons, colors, paths...)?
At the very least it makes the "export" checkbox on attachments useless, which is a shame.

Ideally it would be great to just have the option to save the spine project in JSON or another text format instead of binary (transparently).

Nate

Checking Nonessential saves everything you need to JSON to be able to import back into (the same version of) Spine and have everything that is important be there. Admittedly a few cosmetic or less important things don't make it, mainly editor specific information like the tree expand/collapse state, export settings, most recently used paths, etc.

Unfortunately it is not as simple as just writing a JSON file instead of a binary project file. The binary project file format is extremely complex and JSON (or another text format) doesn't have the features necessary to store the information (eg references). The binary project file format is a big part of Spine's technology that allows us to do rapid development and has other important features, like supporting backward compatibility (reading projects files saved with older versions of Spine).

Exporting to JSON is as close as you can get to storing the project file in a human readable format. You have a good point about the Export checkboxes on attachments, skeletons, animations, and skins not being compatible with this approach. Maybe we could have a setting for ignoring those when exporting JSON.

I would still recommend keeping your project files, otherwise you'll have to import the JSON into a project file (using the same major.minor version that exported the JSON) so you can open the project file in a newer version of Spine, when/if you choose to upgrade. You could version both the project file and JSON file, but then you may have problems where someone forgets to update the JSON file. It may be best to version only the project file and generate the JSON file from it only when you need to do diffs between project files. This works but is a bit inconvenient. Sorry I don't have a better answer!

deck

Thank you for the detailed explanation, at least I have a better understanding of our options.
And yeah having the option to export / import really everything (including the export checkbox and such) might be a good compromise.

Nate

Nate wrote
Maybe we could have a setting for ignoring those when exporting JSON.

Turns out we added this in 4.1. You can use forceAll: true in your export settings JSON when exporting from the command line. We'll rename this to all (either will work) and add it to the UI in 4.2.