- Home /
How does Unity-free source control go wrong
Lucas Meijer has mentioned in previous posts about the dangers of using source control systems in Unity-free. He indicates:
You cannot version Library/*
Versioning the cache and metadata folders defenitely is wrong, and while it may seem to work initially, will always end up breaking your project.
How do I know what I can and cannot put under source control in Unity-free? I'm also concerned with the statement in the second quote that it "may seem to work initially". What goes wrong and how? I don't want to commit my project to source control only to find out that decision itself would corrupt my project...
Also, is debugging support going to be a free or Pro feature?
Thanks.
Richard
To anyone interested in versioning for unity free, as of may 2012, all the 3 answers below offer good advices. Be sure to read them all.
Answer by Murcho · May 28, 2010 at 12:33 AM
To simplify the situation, the Assets folder stores all your raw code and art assets, and any further assets you create inside Unity. It's these assets that require metadata to link together other assets. E.G. When you make a prefab, it stores information about the assets you have combined together in the library folder. The library folder changes a lot, and is basically untrackable with any version control software, other than the Unity asset server. In Unity Pro, there is an option to use external version control, which when turned on actually changes the way the library folder is structured so it can be used with external version control applications.
I've been in your shoes, and version control with Unity Free just isn't a viable option. It sucks, but thems the brakes.
I will say it is possible to version control your code, that won't break anything, and probably your raw art assets, but anything Unity specific won't work.
Ah, ok. Prefab and scene creation go out the window, essentially. That's really ugly...
What about going from Unity Pro to Indie with Version control? For the most part my $$anonymous$$m works with Unity Pro, but occasionally someone will work on the project from home with Unity Indie. Is there any way to keep these files Version controlled without breaking the project?
Answer by yoyo · Oct 27, 2010 at 08:06 PM
We use git to share our Unity-free scene, and it works reasonably well. (git terminology -- clone = make new local copy of repository, pull = sync down latest changes, commit = check in locally, push = post your local commits to the shared repository).
You do need to be a little careful to make this work. Here's how we do it ...
First of all, our folder structure is:
(projectroot)
\ml
\Code
\Art
\Editor
\scene-ml
\Assets --> (projectroot)\ml
\Library
\Scenes
"ml" is our mainline git repository for code, art, etc. This repository is treated just like normal version control -- edit, commit, merge, etc. and push to origin when you want to share with the rest of the team.
"scene-ml" is a second git repository for our scene. This repository is treated as unmergeable -- only one person at a time can make changes that they plan to push out the rest of the team. Under the scene-ml folder, the Assets folder is a symbolic link to the "ml" repository. (See the Windows 7 mklink /D command to create symlinks.)
For day-to-day development, we clone a copy of the scene-ml repository to a scene-local folder. Changes made here are never pushed back to the shared mainline, but can be committed locally for testing.
Git is nice and flexible for pulling down multiple copies of repositories to different local folders, so if I want to see the latest stuff from everyone else I can pull it down as a copy without disrupting my local work in progress.
When you want to share scene changes with the team, you need to update your ml (to get the latest code and art), then delete scene-ml and re-clone, to make sure you have the latest scene. Then make your changes, commit everything back to scene-ml, and push back to the shared repository. We commit everything under the root folder, including Library\cache, etc. After cloning the scene repository, next time you start Unity it will reimport all the assets, which can take a while, depending on your data. If you're worried about having one git repository inside another (the Assets folder points to the ml repository), don't -- git is clever enough not to include the nested repository.
You don't have to use git -- you would get the same effect by zipping up your whole scene folder and posting it to shared storage somewhere. The useful trick we've come up with is putting code and art into a separate (version-controlled) repository and using symlinks to connect these assets to the scene. To do this with zip files you would want to delete the symlink before zipping and posting, then recreate the link when you unzip.
We're using codebaseHQ for our git hosting, a nice cheap solution that has worked well for us so far. We also use the codebaseHQ ticketing system to keep track of who's working on the scene -- ticket #1 is "I OWN THE MASTER SCENE" and always left in status "New". You assign it to yourself when you're making scene changes, then unassign once your changes are pushed to the team.
Caveat: our development is still in its infancy, so we don't have a ton of code, art, big scenes, or a large team. Your mileage may vary! Questions welcome if you want to know more.
I'd vote this up multiple times if I could.
This solution should work with virtually any distributed version control system, including Bazaar and $$anonymous$$ercurial. If you have trouble getting your specific system to support one repo inside another, you can always just add the Assets folder to the ignore list for the scene repo.
Having now attempted to implement this, a word of warning: Unity on $$anonymous$$ac does not deal well with the Assets folder being a symbolic link. It attempts to access the Temp folder both in the actual project directory, and in the directory above where Assets links to, and gets confused. The solution, for me, was to just check out the assets branch directly into the Assets folder, ins$$anonymous$$d of using a symbolic link. Since I have the Assets folder set to be ignored by the scene branch, this seems to work fine.
I'm not on the $$anonymous$$ac yet, though hoping to get there soon, so thanks for the word of warning. And as you've discovered the symlink approach is optional, you can nest the git repositories directly if you prefer. Git is fine with this, and like you say I'm sure other version control systems can be trained to work.
We just tried the symlink approach on the $$anonymous$$ac and ran into the same problem, and the same solution. Neither symlinks nor Finder aliases worked. :-( Note that git understands one repository inside another and does the right thing, so you don't need to do anything special with gitignore.
Breaking news ... turns out that prefabs, stored as .prefab files in the Assets folder, do depend on the library folder if they reference other assets or objects (colours, vectors, numbers and strings are self-contained). Which means you can't get around the single-scene-edit issue by using prefabs.
Answer by Ricardo · May 28, 2010 at 10:39 AM
Actually, you can version what's in the Library directory. There's nothing stopping you, and Unity won't break if you do. The main issue is that since it's full of binary files, you cannot merge it, which means that sharing the repository with anyone and having two people modify the same scene is out of the question. You cannot leave it out of version control either, as Unity would otherwise lose all that metadata. As has been discussed before, that means that branching is right out as well.
This means that you can version the whole thing if you wish to keep the subsequent versions of what you're changing, but if you need to share the project within a team, getting Pro is the way to go.
Having two people modify the same scene at the same time is out of the question, but if you're willing to take turns it can work -- though the workflow is definitely not ideal.
Your answer
Follow this Question
Related Questions
version control - related to another question 1 Answer
Change GIT branch in Unity 1 Answer
Source control & collaboration (without Unity Pro) 3 Answers
How to properly use git with a team? 3 Answers
compiling/modifying Perforce Plugin 0 Answers