I just wondered how other developers use source control with Cocos?
I have been adding the whole project structure (i.e. including all of the cocos source files etc.) as well as the Classes directory.
This means I can easily check out from anywhere, and have a fully developable version of my game.
If I just store the Classes folder, then I have MY files, but have to install the exact version of cocos if I want to develop somewhere else.
But - if I update to a later version of Cocos, then I almost have to start a new repository… But if I am keeping the same repo and just changing stuff in the Classes directory, then checking it out somewhere else, the dev needs to know to install a particular version of Cocos…
Im using Subversion - but I don’t think that makes any difference to the question, but I mention it in case it does
I personally just keep the project minus cocos2d folder as a repo because I don’t like binaries/dependencies in mine (unless they’re header only or something - then I might just go with submodules anyway). I use git.
Integration/upgrading cocos2d-x is a little trickier but that’s why I keep a backup of the entire folder (with cocos2d-x integrated and everything) just in case I find myself screwed and need an exact copy.
and i put just the classes folder, proj.android and the resources folder and some require files.
i know, it may seem a bit odd at the start that you might think.
how can i miss the files, if i dont know how they work.
but it’s in use.
getting a proper .gitignore file is important.
but i am not sure about the versions of cocos2d-x and it’s related allies in source control
After releasing several games on Steam/Android/iOS/Mac I have found that including the Cocos2d-x source code in your repository is a best practice.
You will eventually need to patch (fullscreen, controllers, security, APK encryption, whatever) the framework and to keep those patches (and facilitate merging with upstream changes) you need to have the framework in your source control.
I think I’ll continue to control the whole environment in SVN - for the reasons @corytrese mentions.
The only real problem I have is when I upgrade the Cocos version I either need to start a new repository, or copy across locally and check in all the cocos changes as well as my own - but in a way I quite like that idea, as I can look at what changed easily.
Since I’m also using SVN, merging int code from GitHub or whatever isn’t always super smooth.
What I do is take a patch including all my changes from the last sync forward, then then delete the local repository copy, extract the current release into the folders, and re-apply my patch file.
It has worked for me for a half dozen releases, the only thing that tends to require manual work is converting ‘missing’ files to ‘deletes’ and keeping an eye out for issues with SVN:Ignore properties like *.a or *.so
@corytrese Can you post your .gitignore or similar ignore file. It would be useful to see how you manage the files. Also is there a best practice when it comes to configuration data in files. I have config data in my games header files for Google Play Services, Analytics, etc and would like to remove them from source to a local json file.
@Maxxx if you make a new stuff then you should do that at Feature to not break work of another developers at your team.
personally myself i use Mercurial with Flow extension read more about Flow extension for Git
Wow - a lot has changed in two years!
I’m now using git and not storing cocos in source control!
On the config front, I’m not sure theres a best practice, but plist files are kind of the de facto standard in cocos (due to the IOS beginnings, I guess)
Personally I now use script (I’m using chaiscript because it’s easy) for almost all of my config (some is still in plist files for historic reasons or because it needs updating & I didn’t want to update script files from code)
It’s a great way of doing config, as you can change config on the fly;
