Hi guys, there is a friendly way to work with Cocos Creator and SVN?
In my team two devs modified the same Scene and when tried to merge the changes the scene in question gets corrupted.
Cocos Creator gets every id from the scene index, so, every change (add, remove or change order) in the Node three or add and remove components from a node changes the ids.
The merged scene pointed to incorrect Ids.
Thx.
Hi. I’m also working with at team on game in Cocos Creator. From working with Unity3D we’re use to not working in the same scene due to merging errors. But, we are experiencing another error, after a while of working we get a lot of these messages:
GET http://localhost:7456/res/import/6e/6e01e4d8-e9e5-4363-bc1e-339796d24790.json 404 (Not Found)
I know this is not a solution to the problem, but a related problem(I guess). We’re using git btw.
Never seen an answer to this problem.
It is a huge blocker for team of many coder working on Cocos Creator, and make us not want to switch to Creator at all.
I would go as far as saying this is a deal breaker, making us stay on Studio even if you deprecated it. For us, Creator is not production ready.
It seems Creator use integer as ID instead of guid, so they are not unique, but more over, it re-index everything each time we add a new component.
For a project of multiple persons, this is not managable because no two persons can do even small modification to a scene at the same time.
Sure, big modification will always create conflicts, but they would be way more easier to fix / track with permanent GUID.
Also, I can’t figure out how you track component between scene and there meta data, the ID used seems hashed or something like that. This also prevents easy merge.
I would have happily fixed it for us, but this part of the code do not seems to be open sourced.
It would be nice to receive input in the direction you plan for this part.
Thanks
guid will make scene data files much larger, and even if there are guid and merge with text tool it’s not 100% safe.
We are developing a custom merge tool that can handle scene and prefab merge. Stay tuned.
Hi. The scene format is just base on our common serialization implement, and has nothing special. The serializer doesn’t know something like uuid, it just care about references between objects and use instance id to track them.
However, as you mentioned above, this causes some troubles in VCS.
To resolve it, we can try to use uuid instead of instance id, but it will make scene file size noticeably larger, and it does not assure that merging by common text merge tool will become really safe.
We are developing a custom merge tool that can handle scene and prefab merge. Stay tuned.
+1
Ok, nice to see that you are working on something.
Its true that merge can still conflict. But at least two objects added at the same time from two different persons would each use their own id instead of exactly the same. So all the other reference to them in the scene would not be broken.
Right now, because the indexes are reassigned, when a merge conflict, there is absolutly no way to know which is what in other reference, because the “server” scene and the “local” scene now have different internal id.
I have no problem to resolve merge when I can know what is what, but right now, because everything moved arround it is impossible.
In fact the worst blocker is the ID that are reassigned when something change is the scene.
I tested it, in our biggest scene.
It’s only 130 Ko but it’s still big enough to give a good idea i suppose.
I searched for all “id”: references in the .fire file using notepad ++.
There was exactly 500 occurences of “id”:,
so I found an online Javascript to generate guid, I then made a for loop to generate a string of 500 guid’s back to back.
Then I pasted that string of 500 guid’s in our scene’s file to see the size difference.
It went from 130 Ko to 148 Ko.
That’s with every guid appearing appearing only once, if there were repetitions, which would append in a real-case scenario, then the compressed file should be smaller.
That’s a 13-14% increase in size for having guid instead of Id.
Not to mention that the scene’s file arent the biggest files in a project usually.
Textures and sounds are supposed to be the main weight of the project, or maybe the libs, but correct me if I’m wrong.
My point is,
even if 14% is noticeable, I don’t think it matters in the end.
I would also recommend switching the main ID System for Guid to have more stability as a trade that might end up in projects not even 1% larger.
(1% is a guess, for projects with lots of textures and sounds it might be lower, and projects with few resources it might be worse… definitely worth testing)
Thanks for your test! Now the ID is also used as an array index to find the object. But if switching to guid, we will need to use a dictionary instead of array, which means we should also save each guid as dictionary key. So the increase maybe over 20%, not 13%.
I know its OK for the entire project, but for our potential customer or other engine’s user, they may dislike Creator for this reason.
But I still agreed with your point. We should support guid to have more stability. And we can also remove all guids when project building to keep final size unchanged.
I’m running into the same problem that @muribundi is having. If a coworker checks in code to our git repo, and then I pull the code he checks in, I cannot successfully compile the code in cocos creator. I always get an error: “Cannot find script [HEX_STRING]”
Is this expected?
No, this is unexpected. I think he forgot to commit script’s *.meta file to the repo.
@nantas2 Back in June 2016 you said:
We are developing a custom merge tool that can handle scene and prefab merge. Stay tuned.
Any updates on this? Thanks!
Hello. Have some update for this theme?