I’ve been trying to find documentation regarding versioning. So far it seems it doesn’t exist or requires some serious footwork.
The whole situation just isn’t clear at all.
Am I missing something? We can back up our scripts manually, but what about the Scenes? How do we back up the changes here before implementing new changes?
There are a couple of ways:
- Fork the project (the fork being the backup/versioning)
- Export the project from the dashboard (only available if you are in organisation plan (I use a script to download it so I can commit to local source control))
- Wait for the new checkpoints feature that is in beta at the moment Testing Sprites and Checkpoints
Fork the project:
NOTE: Once you have forked a Project you cannot merge it back into the original.
What’s the point exactly? What purpose does forking do if you can’t pull changes into the master? Or am I missing that option?
Export the project
So if I spend $50 a month, I can export a project. Ok, so does that mean we can import or overwrite a project if we want to revert to an earlier version?
Any thoughts on how this works in a Team environment?
To make a copy of the project. Or to ‘archive’ a version/build. Experiment with something. I usually do this if I quickly want to try a new feature or to quickly prototype/hack out a feature to see if it is worth doing. Or if a production build needs something that should be on the ‘main’ branch (e.g a function code or a key).
I believe so, it’s not something I’ve tried personally.
It’s a new feature that is still in beta. I’m afraid you will have to talk to the PlayCanvas team for feature plans/workflows.
I’m guessing you are looking at how PlayCanvas can be used in a team environment? How big and what would be the make up of the team in terms of disciplines.
Just tried the import option, it creates a new project rather than overwriting an existing one.
And if you like those changes? You just recreate them again in the original project?
So I have to create a version 1.x for each branch?
Well i’m on their forums, and they’re about to take a lot of my money so I’m not sure what else I can do.
Usually when I prototype/hack something, the code is literally held together with duct type just to test the feature and the change itself is pretty small. So doing it ‘again’ means doing it correctly for me.
I’m just answering this question directly. I’m not implying any kind of workflow.
Sorry, I assumed this question was aimed at me.
You could email the team directly and see if they could help you.
In a nutshell, there is no real ‘versioning’ in the source control sense at this stage.
I’ve found PlayCanvas service to work well with a small team. 1 coder and a couple of content creators is ideal. This mainly because the content (models, animations etc) normally exist outside the service and imported in.
My usual workflow is to complete a feature, export the project (via Python script and the API), commit to source control and repeat.
When a build is made, that is tagged in source control and/or I fork and name it appropriately (e.g Iso Base Builder v1.3.1). I rarely do the fork as the source control pick up any changes.
If a bug is found and requires heavy investigation, I normally do this in a fork as it leaves me free to change at will without worrying about affecting the main project.
This whole situation is not ideal and I believe PlayCanvas recognises this given the work they have done on checkpoints already.
Is there something you are looking specifically? For example, do you have a team of coders and wondering how PlayCanvas scales? Or are you simply looking to backup projects up at certain stages?