Single codebase for android, ios, blackberry, etc? Or multiple codebases?

[trusktr]

I'm debating on how to organize my git branches. Any tips?

I'm thinking to make a separate branch for each android, ios, blackberry, etc... But in that case, then there will be duplicate QML and JavaScript files in each branch and I will have to copy them from branch to branch to update each branch.

Can I keep everything in a single branch? How can I avoid having duplicate code across branches?

I'm thinking perhaps I can send the QML and JavaScript through the network, from a server, and thus have QML and JavaScript in a single branch for the server, but that would make things slower (by requiring a network).

Any ideas on how I should implement the git tracking? Will future versions of Qt make it easy to build for different platforms with a single codebase?

[andre]

Perhaps you can take inspiration from Qt itself here? Qt does not use separate branches. Instead, it separates out platform specific code into separate files where possible, and uses #ifdefs where needed.

[trusktr]

I was thinking about something like that, abstraction instead of branching. As of right now, I created a new orphaned branch for Android, and I haven't started iOS yet.

When support for both iOS and Android are officially released, and I start a new QML project in Qt Creator, can builds for Android and iOS (the iOS build would be something I could import to Xcode I'm guessing) be created from a single project? If so, that would be an indicator that abstraction might be preferred over branching.

On the other hand, if the steps for iOS involve creating a substantially different file/directory structure on Mac OSX, then that might merrit using branches instead of abstraction. In that case, perhaps assets like QML, fonts, and images could be made into a submodule required by each branch.

Any thoughts on that?

[andre]

There is actually work going on for that in Qt5. See the "discussion on the File Selectors API":http://lists.qt-project.org/pipermail/development/2013-March/010521.html in the development mailinglist.