(Resolved) C3 is still mostly unusable with source control

As I stated in the github report, I really think UIDs hold C3 back in many ways. I understand moving everything to UUIDs can be a big change, especially for backwards compatibility, but the alternative is trying to do a band aid fix that will not work.

I full agree with Tokinsom here, UID shuffling makes C3 unusable with source control nowadays, which is a huge issue.

For backwards compatibility, UIDs can stay, and UID shuffling can also be kept for a while, but instances should start getting referenced using UUIDs or SIDs (like object types and other editor elements), especially internally.

If more than 1 collaborator adds a new behavior, effect, object type, family, layout, event sheet, script, or timeline, it modifies the .c3proj and creates a conflict.

This should not create a conflict as long as separate parts of the file were modified. It should only be a conflict if two people both try to commit changes at the same time that both affect the same line (e.g. both adding an object to the same folder).

That really is just how source control works - I suppose Construct could load things some other way, but that doesn't prevent conflicts. You'll still get conflicts if two people modify the same image, edit the same comment, change the same instance variable, etc. etc. The best approach to avoid conflicts is to assign clear roles on the team - for example we have clearly assigned code areas for working on Construct itself, so we rarely have to modify the same thing and rarely ever get conflicts.

Again, not the expert here, but sequential UIDs might not be the safest approach.

It's true sequential UIDs don't work well for merging, and it's been a problem before. However I think there's a smarter way to solve this than just adding a whole new kind of UID: in r348 there's a new project property you can change that assigns all UIDs as random numbers with at least 6 digits. Therefore if two people add new objects, the chance they are assigned the same UID is negligible. I think if you set your project in to this mode it should avoid this type of problem happening.

The new random UID option is a life saver. Thanks Ashley.

It should only be a conflict if two people both try to commit changes at the same time that both affect the same line (e.g. both adding an object to the same folder).

Ah you know what in all my testing I was just adding objects to the root objects folder, so that would explain that. Wouldn't introducing new effects/behaviors to the project go on the same line though? I will do some more testing...

Is this a fair summary - for collaborating with Construct 3 today this is recommended as the solution:

1. One team member has to add all assets to the project. And they push that upward to a branch. This team member is in charge of all asset management.

2. Other team members pull from that branch and add interactivity. But do not add new assets. This ensures when they submit changes that the project won't break.

Is that basically the best and easy workflow?

As I said before, usually the only things that will create a conflict is where two people try to modify the same part of the project at the same time. It's explained more in this tutorial.

I'd recommend a workflow where people have clear roles to try to avoid conflicts. For example your proposed workflow does not guarantee that, as "add interactivity" could include a wide range of potentially conflicting changes, e.g. two people could modify the same event block in the same event sheet and still cause a conflict. However if two people are working on separate layouts or separate event sheets, that should avoid a conflict.

Remember even if you do get a conflict, it can be resolved, but it can be tricky - the easiest way is just to roll back and try again. Over time you should get a feel for what kinds of changes are safe and which risk conflicting with your team members, depending on who is working on what.

Thanks, Ashley! First, I'll apologize for being a designer on a team of three designers that don't have access to engineers. We are rapidly building a game for a non-technical client. We all work in the same timezone and need to collaborate during our business hours. The game requires all three of us to be able to add images, sounds, and other files throughout the day.

I read the tutorial that you sent, which is great. But I didn't see an easy solution for us.

To not block progress, here is what I've proposed for us to keep working. BTW, our project is a folder based project, and we have the proper gitIgnore, and our UID numbering is 'Random'.

1. Each day, one person will be the designated person who can add files to the project. Only they can push changes that involve project.3proj. They will push those into the Main branch.

2. For the rest of that day, the rest of the team can make changes that don't change project.3proj. They periodically check gitDesktop to verify they are fine. And we communicate all day to avoid conflicts.

3. The next day, we push our changes to our Main branch and communicate and fix conflicts.

We are open to any feedback. We tested this process this morning, and it worked.

That sounds about right. There are still far too many things tied to the .c3proj to safely have more than 1 contributor add content to a project at a given time.

The other killer is modifying objects that exist throughout the project. For example, if Contributor A adds a variable to an object which exists in all layouts, then all of those layout files get updated. This means no other contributor can edit any one of those layouts without resulting in a conflict.

At least, that's how I remember it happening. Only solution there is Contributor A has to inform others about it so they can push & pull the new object variable before resuming work.

You can work more collaboratively by using a project that is saved as a folder. The folder is full of the project files. So you can merge just the ones you changed. You don't have to merge a massive single project file.

My team of 3 has been working smoothly for 3 days. Just sharing what file with you team and ensuring they all have pushed that file to GIT is all you need to do. It's like checking-out files and virtually locking them. Using human communication.

I'm looking if Git has a file check-out or lock feature for a branch. I think that is how the other branching program PerForce does things.