On Thu, Jun 25, 2009 at 11:25:00AM +0200, Geir Engebakken 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.
>
> What I have found to be the easiest and most maintainable solution is
> to have the specific code extracted to subdirectories, and then let
> the build/runtime process decide what to use.
This is a good solution, provided there is not much overlap between
the specific code directories. Continue doing this if it works for you.
> But since this is such
> an essential problem I suppose there are many ways to solve this, for
> instance by using branches. Any good advice on this ?
Yes, you could branch your code for each customer.
This creates a lot of additional complexity in your development
process, so only do this if the benefits outweigh the costs (e.g.
if managing all those sub-directories becomes unwieldy).
The branches should be thought of as "release branches", in the
sense that they only pick up fixes from the branch they were
branched from (which is usually trunk), or other branches,
but code added to the branch itself is never merged back to trunk
or any other branches.
That is:
trunk ------------------------------------------------------
\ | merge | another merge
\ v v
customer branch -----------------------------------------
In this diagram, the merge arrows always point from trunk to
branch, but never from customer branch to trunk.
The reason for this is that subversion is (right now) not very good
at tracking "flip-flop" merges which go in random directions between
branches. It's possible to do this kind of cherry-picking but it's easy
to end up in a mess if you're not very careful and have a very good
understanding of how merge-tracking works in Subversion and how to work
around its limitations. Because you will hit limitations in the merge-tracking
implementation if you do this.
By Subversion's (current) merge-tracking design, when merging changes
back from the branch to trunk, all changes made on the branch should
be merged back into trunk (this is called a "reintegrate merge").
But you don't want this, since you don't want your customer-specific
changes in trunk.
So merging only one way should be OK in your situation, since the
branch only contains changes specific to the customer and does
not need to be re-integrated to trunk. But make really sure your developers
are diligent in always adding code to trunk first, unless there
really is no other place for the code except the customer's branch.
Else you end up in a situation were you will want to merge code back
in the wrong direction (you could still apply the changes to trunk
manually without merging them, though). You might want to enforce
peer-review before any commit is made to a customer branch for this reason.
Stefan
Received on 2009-06-25 12:00:00 CEST