More level designers workflow

[demostenes]

We have several people working on level design. On 2.5 editor1 it wasnt big issue to merge changes to project from several people in case of conflict. But now each worldsave = change of guid.db. Also adding nodes, etc means changes in guid.db. So how can more people work on the project at once? How we can merge changes in guid.db? Or shoudnt we commit guid.db and it will regenerate itself in deterministic way?

[morbid]

Hi demostenes,

our artists commit guids.db. Conflicts could be resolved as "Use theirs".

[morbid]

Probably, that was too short :)

I've mentioned term "Use Theirs" from Tortoise SVN. I guess in Plastic SCM required command should be named in another way. Changes that you've made in local guids.db could be ignored. Editor will add missing parts of guids.db on the start after you or your colleague will update repo.

All guids are kept in .meta files, as long as you have these .meta files everything should be fine. You even can delete guids.db and Editor will regenerate it. Please note that this process will take some time. A complete guids.db file is also required for your final application to work correctly. 

The easiest way is to commit guids.db every time, on each Editor start it will be modified a little and it's a reason to worry.
The more sophisticated way is to update guids.db before commit, then open editor (it will add missing strings) and after that commit your changes.

We also have plans for removing guids.db from Editor and generate it on-the-fly. That should make designers and artists work more comfortable.

[demostenes]

6 hours ago, morbid said:

1) You even can delete guids.db and Editor will regenerate it. Please note that this process will take some time. 

2) The easiest way is to commit guids.db every time, on each Editor start it will be modified a little and it's a reason to worry.

1) Well, if I delete guids.db, editor will crash after start, there has to be something. But this is no issue.

2) In this case there is no difference to not commit at all, it will be modified anyway...currently we are trying no commit approach.

Removing guids db seems like good idea, but what about big projects? We have 50k+ meta files, so each start would take ages.

Thanks!

Edited May 3, 2018 by demostenes

[morbid]

21 hours ago, demostenes said:

Well, if I delete guids.db, editor will crash after start, there has to be something. But this is no issue.

We also caught this crash on the stage of asset validation. I guess removing guids.db is not the reason that caused it.

21 hours ago, demostenes said:

2) In this case there is no difference to not commit at all, it will be modified anyway...currently we are trying no commit approach.

Is update - run editor - commit really uncomfortable? I assume you have to update the content before commit anyway, right?

21 hours ago, demostenes said:

Removing guids db seems like good idea, but what about big projects? We have 50k+ meta files, so each start would take ages.

Well, I hope there is a way to optimize this workflow. Our team familiar with this task, we'll try to figure something out.

[demostenes]

12 minutes ago, morbid said:

Is update - run editor - commit really uncomfortable? I assume you have to update the content before commit anyway, right?

Well, main reason why to not commit guid.db is HDD space (DB grow) on the version control system server. Each commit  means cca 16MB of data you dont need. There is of course no difference in workflow. If we have no issues with this approach, we will not commit it, if we have, we will commit, not big difference though. I was just interested in exact mechanism how this works. I think it would be good idea to put it into documentation (more developers/artists workflow how to...). 

Btw, regarding space, new terrain global changes some pretty big files if you paint texture, so for example painting 1 sqaure metr of terrain with grass causes 1GB of data to change. So this will cause very fast grow of our version control system DB. Older terrain object was far more efficient in this, it changed only affected area files.