5

I have developed a web application for a client which is live to their customers. Recently, the application has been sold in such as way that it is replicated to other domain names so there are 4+ instances of the application which I am to develop and maintain.

At the moment, each copy of the app has it own SVN repository and when it comes to making changes to the application that effects all instances, I update one and then use Beyond Compare to merge changes over to the other copies.

Would it be a better solution to use svn branches to maintain a core system and to merge out to sub branches and visa versa for bugs? Each application may have changes made to it that are client specific, such as logos, colours etc.

Are Branches the best way to go or continue to have each in their own repository and use BC to merge where necessary?

Improve this question
3
  • The application hopefully was designed to handle client specific aesthetics and thus what you are updating is the core or controller of the application. Commented Dec 15, 2010 at 19:15
  • Yeah I was going to ask what is the difference between the 4 versions? Is it something that could be parameterised in your build process? Or something that could be turned into a configuration detail? Commented Dec 15, 2010 at 19:25
  • At the moment, the differences in the applications are cosmetic and they could be configuration options. In the near future though each may have features that the others don't. Commented Dec 15, 2010 at 19:41

3 Answers 3

Reset to default
4

Its going to depend on the specifics of course, but ideally you'd want a single source code base with extensions for the client specific code. For example, you might organize the client specific code into plugins the way a content management system would. Or use a templating system for custom GUIs. I would try to avoid maintaining 4 sets of core code if at all possible as thats just asking for problems. Especially if a year from now thats 10 sets of code as you add customers.

As another example, the largest PHP app I work on has an administrator interface that lets the admin enable or disable specific features. Some are designed for single clients only, others are 'premium' features that multiple customers have upgraded to. But its still all one code base. During runtime, it checks based on who's logged in, and presents the user with additional functionality where applicable.

Improve this answer
2
  • Hi GrandmasterB, Thanks for replying. It would make sense to go back to the client and programme the differences in to one system and make them configurable options. This way I don't have to maintain several applications. Thank you. Commented Dec 15, 2010 at 20:39
  • +1 for the single codebase with all features being switchable. Configure with a separate admin app. JMX does this in Java to allow instant reconfiguration without restarts. Commented Dec 15, 2010 at 22:08
2

The typical approach is to have a single core, which can then be configured as needed in a separate module. For simple cores, you can make do with if-statements based on variables in the configuration module.

For more advanced cores, you need to be able to provide customer specific code overriding standard functionality. How exactly this happens (compile time, versus runtime) depends on what is most convenient for you.

But you desperately need to consolidate your code in a single code base. Otherwise the complexity will quickly overwhelm you if you get more customers.

Improve this answer
1
  • +1 for emphasising the single code base - vital in managing the complexity of the project. Commented Dec 15, 2010 at 21:59
1

Distributed version control where you have a separate repository for each instance and commit the changes to them as needed.

http://hginit.com/ might help understand it.

We're in a similar situation and it's not something Subversion does well at all. We're looking at Mercurial as an alternative.

If that's not a short term option you need to separate each instance out into core code (which can be shared) and code which can not. This at least minimises customer specific code and makes the scale of the problem smaller.

Improve this answer
2
  • Hi Jon, Thanks for responding. Its good in one way to hear its something Subversion doesn't do well at as I was worried that I was overlooking a fundamental facility of Subversion, ie Branches. Thanks for the link to hginit.com too, haven't seen that before. Commented Dec 15, 2010 at 19:21
  • 1
    Don't do this using branches. You basically need to be able to see ALL the code at once to be able to deal efficiently with it. Commented Dec 15, 2010 at 20:57

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.