Re: Customer branches

On Thu, Jun 25, 2009 at 5:25 AM, Geir Engebakken<geir.engebakken_at_edb.com> wrote:
> ..... Or how to maintain several adaptations of the same code.
>
> This is a problem that I suppose has more to do with
> general SCM than Subversion, but I am wondering what is
> the "best practice" regarding maintaining several versions
> of the "same code" where there are minor changes for
> different "customers" or "techniques" for that matter,  in
> Subversion.

Can you say "Can 'o Worms?". I knew you could!

It really depends upon how complex these code changes are between
customers and how extensive they are.

I can imagine several solutions:

1). Use templates for these files, and build the actual files during
the build process. For example, you have a file called "deploy.xml"
that contains customer specific values for certain properties. In Ant,
you could use filtering and a properties file to set these values to
the specific customer.

You can do a similar thing with C's preprocessor which can do a lot
more complex file modifications. (I've used the C preprocessor on
non-C code.)

Advantage: It's simply and easy to maintain. Only a single file has to
be updated.

Disadvantage: It doesn't work if customer differences are more than a
few changed lines.

2). Keep separate versions of customer specific files. (Like what
you're doing right now).

Advantage: Except for the few separate source changes, most of the
cost is the same. It's pretty simple to implement.

Disadvantage: If a feature is added or bug is fixed in one of the
customer specific files, you now have to manually remember to
duplicate that fix for all of your customers.

3). Branching: Each customer gets their own branch.

Advantage: If you make a change in customer specific code, you can
merge these changes to all of your other cusomers.

Disadvantage: Each change, even in files that are not customer
specific, now requires you to merge that specific change to all of
your customers.

What it comes out to is trying to balance out maintaining multiple
versions of separate customer files. The best solution is to keep the
files as similar as possible. Failing that, determine how best to keep
the various customer specific files in sync with each other.

There is no one correct way. It all depends upon how different and
vast the differences between your customer's code is.

Unfortunately, it is quite easy for a company to make a valuable sale
without fully realizing the cost of that sale. I've been in many
situations where a company I worked for made promises in how we'd
modify our code in order to make a sale, then get upset when I tell
them the actual cost of keeping those promises.

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2365393
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].