2 added 1353 characters in body
source | link

What you need is feature branching-like code organisation. In your specific scenario this should be called FeatureClient-specific trunk branching is probably what you're afterbecause you'll likely use feature branching as well while you develop new stuff (or resolve bugs).

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

The idea is to have a code trunk with new features' branches merged into. I mean all non-client-specific features.

Then you also have your client-specific branches where you also merge same features' branches as required (cherry-picking if you will).

These client branches do look similar to feature branches although they're not temporary or short-lived. They are maintained over a longer period of time and they're mainly only merged into. There should be as little client-specific feature branch development as possible.

Client-specific branches are parallel branches to trunk and are being active as long as trunk itself and don't even get merged as whole anywhere.

            feature1
            ———————————.
                        \
trunk                    \
================================================== · · ·
      \ client1            \
       `========================================== · · ·
        \ client2            \
         `======================================== · · ·
              \ client2-specific feature   /
               `——————————————————————————´

Feature branching is probably what you're after.

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

What you need is feature branching-like code organisation. In your specific scenario this should be called Client-specific trunk branching because you'll likely use feature branching as well while you develop new stuff (or resolve bugs).

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

The idea is to have a code trunk with new features' branches merged into. I mean all non-client-specific features.

Then you also have your client-specific branches where you also merge same features' branches as required (cherry-picking if you will).

These client branches do look similar to feature branches although they're not temporary or short-lived. They are maintained over a longer period of time and they're mainly only merged into. There should be as little client-specific feature branch development as possible.

Client-specific branches are parallel branches to trunk and are being active as long as trunk itself and don't even get merged as whole anywhere.

            feature1
            ———————————.
                        \
trunk                    \
================================================== · · ·
      \ client1            \
       `========================================== · · ·
        \ client2            \
         `======================================== · · ·
              \ client2-specific feature   /
               `——————————————————————————´
1
source | link

Feature branching is probably what you're after.

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html