CODEWITHSUNDEEP
svnconfigurationmergebranchproject
Toskan
Toskan

Reputation: 14931

Having 2 products from one SVN project - how to keep certain changes only for one product?

So we have application Pluto and an application Goofy - both use the same SVN Project. There in fact is only a little configuration difference.

Now I face this problem: customer from Pluto wants some new changes - in Detail, he wants added functionality to Javascript and some xhtml tags we use in our JSF environment. Basically it's an improvement javascript-wise he's asking for - the old functionality must still exist. But: the new functionality could destroy parts of Goofy, since Goofy is a much much larger application and hard to test. Actually Goofy is a superset of Pluto - e.g. Goofy can do whatever Pluto does - but in fact it is only for testing, the final Product resides in Pluto.

The files which require changes are pretty static, I think the last change to one of the files is more than half a year ago. And there are certainly not more than a couple changes in the last two years.

What I thought about is creating a branch for Pluto where I implement all changes to javascript and xhtml tags. The developers will develop on trunk and I will always merge the changes from branch before deploying (this could probably be done automatically). But: there is a problem about local development - since it is trunk and the new functionality is only on the branch, the new functionality will not be available when developing locally for Pluto.

Another approach would be to use e.g. if application==Goofy load javascript Goofy and vice versa.

Or finally - try and error, e.g. just merge all changes and fix bugs :-)

How would you guys decide on this?

Upvotes: 3

Views: 62

Answers (1)

Avada Kedavra
Avada Kedavra

Reputation: 8691

I'd use different branches and accept the inconvenience of merging over using special tricks like if application==Goofy any day of the week. When the complexity of you programs increase and maybe more applications are added the latter implementation will bite you back for sure.

Another approach which may better work for you, is to refactor your code and break out the core parts of the applications into its own project(s). Then let each application reference the core project(s) separately. For example the core part could contain the business logic while Goofy/Pluto handles the GUI and/or special implementations on some of the core parts. Your SVN tree could look something similar to:

trunk
  |--- Core stuff
  |--- Project Pluto
  |--- Project Goofy

A more complicated, but very flexible, approach would be to move Core stuff to its own repository. You could then use svn:externals to include the core parts into your projects. This would give you the benefit of being able to lock Pluto and Goofy to certain revisions of Core Stuff. Thus, you can update Core stuff to add more functionality which is needed for one project but harmful to or undesired in the other. I've seen this in action and it worked great. We had legacy code that was very outdated but still compiling and working even though the core parts had been upgraded for years since the development of the legacy projects had stopped. 

Core trunk
  |--- Core stuff (rev 123)

Application trunk
  |--- Project Pluto (Core rev 111)
  |--- Project Goofy (Core head)

The blog post svn:externals should be helpful if you want to play around with the last option.

Upvotes: 3

Related Questions