Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
The application hopefully was designed to handle client specific aesthetics and thus what you are updating is the core or controller of the application. –  Chris Dec 15 '10 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? –  JohnL Dec 15 '10 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. –  Gortron Dec 15 '10 at 19:41

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer
    
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. –  Gortron Dec 15 '10 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. –  Gary Rowe Dec 15 '10 at 22:08

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.

share|improve this answer
    
+1 for emphasising the single code base - vital in managing the complexity of the project. –  Gary Rowe Dec 15 '10 at 21:59

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.

share|improve this answer
    
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. –  Gortron Dec 15 '10 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. –  user1249 Dec 15 '10 at 20:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.