We have a mobile app that we want to propose to multiple (B2B) clients. The app will be published to end customers on their behalf, but all the development will be done by us.
So far, we’ve built the prototype application. This one will be always be taken as master and undergo rebranding and maybe slight functional modification to end up as a concrete version for a specific customer. Eventually, there will be multiple variations of the prototype application.
Features and bugfixes will be developed in the prototype application and we want to use SVN to merge these changes into the specific client applications. The different concrete applications will have their own lifecycle and versionning each.
Should we use branches, different repositories with changesets,…? Can anyone give us a head start on how we should organize our SVN repository/ies to enable this?
If each concrete installation will have it’s own lifecycle and versioning, then you will need the ability to branch and tag each one independently. However, to simplify merging changes from the prototype into each specific version, all versions should be in the same repository.
So I would build a repository along the lines of:
If there is any common code that applies to all installations (i.e. white-labelled code) then I would store that in a separate (Common) repository and bring in the dlls via SVN Externals.
Where ExtLib represents a link into a specific Tagged Revision of the Common Code.
Basically, keep as little code as required in the Prototype/Specific Version branches.