I find Unity projects somewhat fragile. It’s frustrating because if I break my program, what I want is to either review my changes via diff, or be able to revert to a previous version. But Unity and source control do not get along very well.
Perhaps someone has tips on this? Ultimately it may come down to requesting new Unity features but first I’d like to understand better what currently works and how best to use it.
Script files: can be version controlled, and can be diff’ed.
Prefabs: cannot be source controlled, as far as I know. Cannot be diff’ed.
Assets: you can manually export/import them. This is better than nothing… Perhaps one could write an editor add-in that would snapshot all your assets to a place where you could version-control them? Or maybe it could even issue the version control command for you.
Scene files: ??
Discussion:
We can snapshot assets and scripts. If only we could snapshot the rest of the project too. But of course we can- by compressing the entire thing into one file and version-controlling that. So what if we version-controlled all Unity file separately, but resolved to only check the entire project in or out at the same time? This would give us checkpoints, if nothing else. Would this work? I think Unity would barf but I haven’t tried it.
Unfortunately even if we can version control the entire project there seems to be no solution for diff-ing scenes/projects and seeing what changed. I wonder if OTEE could one day implement a text dump of an entire scene or project (perhaps .XML format) that could be used for diff’s? Even better if this file could be imported again, and coupled with asset files and scripts, would recreate a project. Barring changes to the Unity file formats themselves, this might be the next best thing. Or am I the only one who would want this?
Since scripts are both diffable and version controlled without difficulty, one thought is to do as much as possible in scripts. For example, I could write a global factory class that contains the connections to all of my games’ prefabs. Other objects would ask it to instantiate the prefabs. This would put all the prefabs in one place. Downside: Unity wouldn’t know which prefabs aren’t being used, and thus wouldn’t be able to automatically strip out the unused ones. This could be fatal on a large project, unless maybe you wrote a separate factory for each scene.)
Similarly, setting component properties in scripts rather than in the properties editor increases the trackability of property changes. After playing around with an object’s properties manually one might eventually move those settings into code, or load them from a private file format or from game prefs… I wonder if it’s possible to write a Unity script that dumps all the properties of an object as an alternate format, or as a series of script commands that (if compiled) would set all the properties?
–
That’s my current thinking on this topic. I’d be very interested in hearing other people’s tips, suggestions, and corrections.
First of all. We are working on a solution for this but it might be a bit further down the road. So thinking about alternative solutions until we implement it properly makes sense for those who are used to version control.
binary2text is a commandline utility that does exactly this.
Basically the whole issue of using svn to version control unity projects revolves around this.
Unity stores a lot of meta data with each asset. Eg. A texture has import settings like convert heightmap to normal map. The meta data is stored in a different file and a version control system has to check in both in order to work completely, but this is not really possible unless you tightly integrate it with unity.
In short just checking in the Assets folder into svn won’t get you a completely versioned project.
As far as i can see it makes most sense to just put a few files in version control. And then create backups of the whole project once in a while.
Files which you can safely version control are:
.unity scene files and scripts.
prefabs can be version controlled but you need to make sure that unity is not running at the same time.
You could also put fbx, mb files or textures into version control.
You won’t get import settings that way but you usually dont change them very often.
It’s definately not a bullet proof solution and you need to be smart about what you put into version control but those who are familar with svn might like it better than having no version control at all.
I appreciate the tips, Joachim! Between the extra information you gave, the binary2text command, and the fact that in the long term there might be a more complete solution, you’ve given me a lot to work with.
I just ran binary2text on one of my scene files; pretty interesting output! There’s a lot of flattened data naturally and other unparsable things but there are recognizable properties as well. An excerpt for the curious:
Camera
m_ExtensionPtr (PPtr<EditorExtensionImpl>)
m_FileID 0 (SInt32)
m_PathID 65 (SInt32)
m_GameObject (PPtr<GameObject>)
m_FileID 0 (SInt32)
m_PathID 58 (SInt32)
m_Enabled 1 (bool)
m_ClearFlags 1 (unsigned int)
m_BackGroundColor (ColorRGBA)
r 0.158026 (float)
g 0.178356 (float)
b 0.317525 (float)
a 1 (float)
m_NormalizedViewPortRect (Rectf)
xmin 0 (float)
ymin 0 (float)
xmax 1 (float)
ymax 1 (float)
near clip plane 0.1 (float)
far clip plane 1000 (float)
field of view 60 (float)
is ortho graphic 0 (bool)
orthographic size 100 (float)
m_Depth 0 (float)
m_CullingMask (BitField)
m_Bits 65535 (UInt16)
m_TargetTexture (PPtr<RenderTexture>)
m_FileID 0 (SInt32)
m_PathID 0 (SInt32)
I could envision finding a change I made to a property based on a diff of the scene dumps. Are there any other types of files that might be useful to dump?