- Home /
How to merge in Asset Server?
Our team use Unity pro 3.4.1, and we use Asset Server to do version control. Two of our guys modify the same scene, but their work can't be merged together, the merge button in Asset Server window is always disabled. Now we must limit only one person to make one scene, but we need cooperation. How do we merge works made by several people to same scene? Unity has lots of such painful defect.
Answer by Graham-Dunnett · Oct 21, 2011 at 01:17 PM
There is no solution to this, currently. Only a single person can work on a scene at a time. (Same it true for Prefabs). If you can tell us more about what these two dudes are doing then maybe we can think of a different way of working.
Our artist will make the scene first, then our level designer will add some objects according to gameplay. $$anonymous$$aybe our programmer will also do some stuff in the same scene. How do they cooperate?
Answer by Prophet · Feb 21, 2012 at 08:47 PM
I also want to know this!
"Our artist will make the scene first, then our level designer will add some objects according to gameplay. Maybe our programmer will also do some stuff in the same scene. How do they cooperate?"
Can someone post their experience about this?
Thanks!
This has always been a problem for visual assets. And it's your workflow, not Unity. In your example, suppose the artist puts a giant foot where the level designer put a $$anonymous$$onty Python sign. Who gets priority? Who gets to decide? Here is a reasonable workaround:
1) The artist checks in his or her work frequently, completing work in one area of the scene and then moving to another.
2) The artist tells the level designer and programmer which area is done.
3) The level designer can place things in that area. Yes, I know those things will go away when he or she gets the next artist build. But the level designer can record the transform position and rotation (copy and paste into notepad) so repositioning existing assets will go fast. Alternatively, the level designer can import those objects into a dummy project called WorkingBackup or some such, delete those objects from the live project, get the art build, then reimport those objects into the live build.
4) The programmer can script to his or her heart's content as long as he or she keeps the script locally. The programmer can test the script in an empty or completed part of the scene. Then keep a local copy of the script, get the latest from the artist or level designer, reattach the debugged script, et voila'! Or the programmer can follow step 3's instructions about WorkingBackup.
This should add 2-3 $$anonymous$$utes per handoff to the process, but that's a lot better than losing work or not being able to work at all.
Answer by RFAronson · Jan 03, 2013 at 09:34 PM
This has always been a problem for visual assets. And it's your workflow, not Unity. In your example, suppose the artist puts a giant foot where the level designer put a Monty Python sign. Who gets priority? Who gets to decide? With text comparisons, such as scripts, it's usually easy to say "Use this code, not that code" as one will be more recent with a lot of stuff unchanged between the two, and just using the changed stuff. But with repositioning, you need to put the foot or the sign in a brand new place; it's not just a case of selecting which one to keep. Here is a reasonable workaround:
1) The artist checks in his or her work frequently, completing work in one area of the scene and then moving to another.
2) The artist tells the level designer which area is done.
3) The level designer can place things in that area. Yes, I know those things will go away when he or she gets the next artist build. But the level designer can record the transform position and rotation (copy and paste into notepad) so repositioning existing assets will go fast.
4) The programmer can script to his or her heart's content as long as he or she keeps the script locally. The programmer can test the script in an empty or completed part of the scene. Then keep a local copy of the script, get the latest from the artist or level designer, reattach the debugged script, et voila'!
5) If bugs are found that require changes upstream (level designer or artist from programmer, for example) import the debugged potentially affected object(s) into another project, let the bug fixes occur, download the changes, and then import the backed off object.
This should add 2-3 minutes per handoff to the process, but that's a lot better than losing work or not being able to work at all.