[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Many customers with few changes to source

From: Steve Greenland <steveg_at_lsli.com>
Date: 2005-02-18 17:37:43 CET

On Fri, Feb 18, 2005 at 11:15:15AM +0100, Kurt, Oliver wrote:
> On the one hand, we've a source tree with thousands of files and folders. On
> the other hand we've many customers and these require some changes to the
> programm.
> So far we used visual source safe (but it sucks) and we had a structure like
> that:
> \trunk => c:\trunk
> \trunk\our_programm => c:\trunk\our_programm
> \trunk\our_programm\customer_1 => c:\trunk\our_programm
> \trunk\our_programm\customer_2 => c:\trunk\our_programm
> \trunk\our_programm\customer_3 => c:\trunk\our_programm
> \trunk\our_programm\customer_4 => c:\trunk\our_programm
> \trunk\our_programm\customer_5 => c:\trunk\our_programm

I'm not completely sure what your situation is, so I'll provide two

If you have files that are part of the standard product, and modify them
on a per customer basis, then in subversion, I would take this approach

Main tree:

Then branch it for each customer:


When you code for customer 3, switch to that branch. If you make changes
that are appropriate for only that customer, just check it in. If the
change is needed for everyone, also merge it back into the trunk, and
then merge *that* into each customer branch. Yes, it's tedious.


If your customer specific files are completely distinct from the shared
ones, and you can setup your build tree to have the shared files in a
subdirectory of 'customer n', then svn:externals will possibly work for

On a complete side note:

If you're in the situation of my first proposal, where you're modifying
code on a per customer basis, You Are On A Really Bad Path. Seriously.
I've been in organizations that started doing custom versions for
each customer, and it's a support nightmare. In each case, it took a
lot of effort and time and customer maintenance to get them back to a
standardized product with proper configuration possibilities. The sooner
you make the change the less painful it will be.

Which is not to say you can't have a toolkit and do custom apps for
clients. But keep the toolkit distinct from the custom stuff. If part of
the work for a particular client has toolkit possibilities, pull it into
the toolkit and treat it as such. Don't get them mixed up.


"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
                           -- (Stolen from the net)
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 17:41:15 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.