Re: Many customers with few changes to source

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
answers.

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:
our_program/trunk

Then branch it for each customer:

our_program/customer_n

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.

OR

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
you.

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.

Steve

-- 
"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