Strategy for branching in subversion with mobile releases

Question

I'm developing a series of applications for mobile devices, we'll call them Orange, Cherry, and Pear. Now, because of my familiarity with Blackberry, I chose to begin implementing the first of these three applications, Orange, on the Blackberry platform. I found a way to integrate a number of Blackberry platforms (since they use relatively the same API among different BB operating systems, with some exceptions) into the same codebase. Currently, my codebase looks something like this:

Orange/
  trunk/
   src/
     ... orange's source tree...
  branches/
    1.0/
     ... orange's source tree as it looked at release 1.0 ...
  tags/
     1.0.0/
     1.1.0/

So, basically, I'm using a version-based methodology to my branching. Now, however, we want to migrate this application to the Android platform (and, at some point in time, probably to other mobile or even desktop platforms). So, my question is, what is the best method for branching with a single application across multiple platforms? I have read http://stackoverflow.com/questions/34975/branching-strategies, as well as a number of branching strategy webpages (e.g. http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html ), but I'm still unconvinced at branching based on having a 'common' trunk (e.g. as described in the last link as 'Branch per Technology').

The reason I remain unconvinced is that I'm a believer in the version-based branching strategy. It seems logical; if you want to maintain separate stages of development, then branches seem like the ideal way to do this. If I have aspects of the code that are 'common' between all three platforms, then I decide to make an android release, do I branch all of the code from the common and android trunks to make a new release tag? Or, do I keep all of the code in the 'common' branch in the android and blackberry branches as well?

I thought that perhaps another thing I could do would be to create separate projects, for instance orange-blackberry and orange-android. This might clutter my svn repository, however, since we keep all of our projects in the same repository. So, inevitably, I will have orange-blackberry, orange-android, cherry-android, cherry-blackberry, pear-android, pear-blackberry, along with a series of project folders for any other application I create.

So, I'm looking for some feedback about what might be the best way to manage all of this chaos. Also, if you could throw in some ideas about the logistics of transferring from my current implementation to the newer one, (i.e. what svn commands I should use to maintain history), that would be very much appreciated.

Answer 1

BlackBerry Java code is j2me, so source code must be Java 1.3 compliant. Android can use Java features all the way up to Java 6. If you want your app to look decent, you will be using the RIM proprietary UI components (net.rim.device.*) and those won't be available on Android.

I wouldn't consider an Android version of an application to be a branch of BlackBerry. You should just start from scratch. The platforms will share very little code, and the code that can be shared would be best factored into a library jar that both project incorporate.