[Phpwm] Version control - project organisation

[Ian Munday]

I'm hoping to pick your brains about version control - not in its  
general use, but in how to organise projects.  Let me try and explain...

I have a product which, like any other, get upgraded over time and new  
releases (tags) are made.  Some clients use the "standard" version,  
but they'll almost certainly require customisation to a couple of  
files.  E.g. language terminology and a logo:

	/lang/en_GB.php  *
	/public/images/logos/company-logo.png

* Clients don't need to be foreign speaking to require changes to this  
file, they may simply use different terminology for the same objects  
in the system.  This can be quite a large dictionary of changes, not  
just half a dozen key words.

The problem I'm having is managing all these different variations in  
Subversion (or any folder system for that matter).  This problem  
doesn't really disappear by moving the customised data to the database  
as I'd just end up storing SQL files.  I've effectively ended up with  
a branch for each client, with their own trunk, and their own tags.   
So much of each client version is common to the standard trunk and I  
end up doing a lot of manual replication to ensure all the client  
trunks are kept in sync with the "standard" trunk, and that all  
clients have their own tags marked accordingly.  E.g.

	/project/trunk
	/project/tags/release-1.0
	/project/tags/release-1.1
	/project/tags/release-1.2

	/project/clients/client1/trunk
	/project/clients/client1/tags/release-3.0
	/project/clients/client1/tags/release-3.1
	/project/clients/client1/tags/release-3.2

	/project/clients/client2/trunk
	/project/clients/client2/tags/release-3.0
	/project/clients/client2/tags/release-3.1
	/project/clients/client2/tags/release-3.2

This can be further complicated when certain clients require even  
heavier customisation.  In these instances, the majority of the code  
is shared with the standard project, but they may require some  
database changes on key tables, and a few screen changes to  
accommodate this.  I've ended up adopting a version scheme which is  
essentially records both the client version and the standard version  
on which it is based, i.e:

	<client-version> (<standard-version)

And in Subversion:

	/project/clients/client3/trunk
	/project/clients/client3/tags/release-1.0-(3.0)
	/project/clients/client3/tags/release-1.1-(3.1)
	/project/clients/client3/tags/release-1.2-(3.1)
	/project/clients/client3/tags/release-1.3-(3.1)
	/project/clients/client3/tags/release-1.4-(3.2)

This isn't really a big burden when I'm managing only a few clients  
(although it does seem unnecessarily repetitive), but as this numbers  
grow it becomes more a more unwieldy.  I'm thinking there may be a  
better way...?

For example, by having one project for the whole of the standard code  
base and versions, and a second project for managing the few files  
that are likely to change between clients.  E.g.

	/project/trunk
	/project/tags/release-1.0
	/project/tags/release-1.1
	/project/tags/release-1.2

	/client1/lang/en_GB.php
	/client1/public/images/logos/company-logo.png

	/client2/lang/en_GB.php
	/client2/public/images/logos/company-logo.png

When making a release, I then merge the two together using a tool such  
as Phing.

Does anyone manage a similar scenario?  I'd be interested to know how  
they do it, and where I can ease the maintenance burden.

Regards,

Ian