views:

155

answers:

2

I currently have a web app that has 3 front ends (depending on what URL you go to) that shares very little code between the 3 front ends. My directory structure looks like this:

\app1
    \includes
    \html
\app2
    \includes
    \html
\app3
    \includes
    \html
\crons
\libs
\logs
\setup
    \db
\shared
    \globalFunctions
    \oldAPI
    \oldClasses

The App folders are the individual front ends with their own inclusive includes and docroot's in 'html'. Crons is just for CLI jobs, libs are newer PHP5 libraries such as the new code we write and things like Zend Framework. Logs are app logs, setup is setup info for deployment, and shared is the old PHP4 codebase that some of the code still relies on. Everything is stored in one big SVN repo.

What would be a sane way to break this up so that I can turn this one big SVN project into smaller ones so that it would make it easier to branch and merge? Most projects focus on a single app anyway so it is rare when code needs to be updated in multiple places.

Or is it better to keep this current structure and just go along as we port the PHP4 code to OO PHP5 and naturally drop things out?

+1  A: 

Reality Check

You need to ask yourself what value will I get in dividing this application up and what it will cost me. Then if you still want to do it think about how breaking a large application up into smaller ones is a feature and how adding features that are not required is worse than not adding required features. This falls under LEAN software development.

Dividing your application into multiple applications

Here is what I would do. I'd take your shared code and turn it into a library. This library would be documented and treated as it's own project. I would also create separate deployment scripts for each application and a master deploy script to deploy all of them at once.

\app1
    \docs
    \includes
    \html
    \logs
    \setup
        \deploy
        \db
\app2
    \docs
    \includes
    \html
    \logs
    \setup
        \deploy
        \db
\app3
    \docs
    \includes
    \html
    \logs
    \setup
        \deploy
        \db
\crons
\deploy
    \docs
    \apps123
\libs
    \newSharedLibName
        \docs
        \globalFunctions
        \oldAPI
        \oldClasses
    \zend
    \etc ...

I left cron alone since I'm not sure what your doing with it.

p.s. Splitting an application into smaller pieces is always harder than you think.

gradbot
+1  A: 

You could split it into four SVN projects - one for each of the three apps and the fourth for the rest of the code. You can then define this shared code as an external for each of the individual apps so they can run as a self contained checkout.

That does get you your separate projects but comes with its own set of problems - mainly if you update the shared section for one app you have to regression test the other two to check you haven't broken any dependencies.

This is probably more hassle that it's worth but it depends on how you work.

Colonel Sponsz
I agree, Using svn:externals for internals is a good option here
Bob Fanger