source control CVS ?

Anyone using source control with Unity?

 

Neil and I are using subversion to version control the scripts. You can only do it with the scripts (and shaders) though, not the art, or project files, or anything else.

 

I've been thinking about this too. Version control isn't optional for any serious project, and Subversion handles binary files very well (unlike many other version control systems, it has proper binary delta support).

Unity reflects changes in asset arrangement directly back to the file system, and this will confuse svn unless it is informed of the file relocations. However, Unity also automatically updates its metadata on available assets whenever the file system changes, and uses hashes to check file identity. So it would seem that provided you are happy to only rearrange your assets with svn (you can still create and delete assets within Unity), they should play together nicely. I'm experimenting with this at the moment -- I'll post my results back to the forums.

 

Based on what's been said in this thread, it sounds like any kind of source control may not be a good idea, or a serious challenge to say the least. The recommendation seems to be to import and export packages as the check in/out method.

 

OK.. I think I've read everything previously discussed on Unity and source/asset version control now, and I no longer consider asset rearrangement outside of Unity a good idea. However, I remain unconvinced that packages are the best way to version assets.

You could build a version control system using packages, but what you end up with is somewhat limited. Firstly, the granularity of the version control would be very coarse. Diff'ing individual assets would require two checkouts, and two imports into a temp project workspace. Secondly, there would be a high probability of missing changes due to the manual export required before committing a change. If you altered an asset outside the logical package you were working on, this would be hard to detect, since an "svn status" command wouldn't help. Thirdly, packages in Unity appear to be obfuscated and, expect for a small header, every time a package is exported the byte-stream is different, even if the assets are identical. Presumably this is to protect access to raw assets when shipping a game. This may be a useful feature, but it means binary delta compression in subversion will be of little value.

So I still think individual assets are the best basis for version control, although FWIW, I think packages are potentially a great way to provide a binary output in a component based build system. I like the idea of having a "base" Unity project to own our core shared scripts, materials etc. Then importing the assets as a package into other projects. But in this scenario the package would be the build artifact, not the unit of source control.

There have been a couple of comments stating that placing assets in Subversion won't work, because Unity maintains metadata on the these assets in the Library folder (within the project) in a GUID/hash based map. Changes to asset files may result in metadata files being added or deleted. Personally, I can't see how this prevents source control; surely it just means that all changes to the metadata need to be atomically committed alongside the changes to the assets themselves. This is slightly difficult for two reasons. Firstly, because working out which asset changes resulted in which metadata changes isn't trivial; although parsing the guidmapper file looks pretty simple, I'd rather not implement something that's liable to break when Unity itself changes. That said, even being restrained to submitting all the changes to a project seems better than the package based approach above. At least you'll have a per-file history, so if you wanted to reapply a known set of changes to a clean checkout of the project (eg, back-porting bug fixes to a stable branch), this would be much easier.

The second problem is that since you'll be moving, adding and deleting assets within Unity, you'd need to update subversion's knowledge of these files to ensure an "svn update" doesn't bring down a load of files in their old locations. So what is really required is a subversion minimal-remap script to ensure that files added, deleted, and moved within the project are captured in the repository. This is trivial if we confine ourselves to modeling moves as plain add/deletes, although this would mean that every time an asset is moved within the project, its history would be lost. Working out where assets (or whole directories of assets) had moved via a message-digest based file comparison would much smarter, but I haven't seen anything like this before, so it would have to be written from scratch.

An alternative to this problem may be to use subversion WebDAV support -- but I have yet to investigate this at all.