Re: Sticky branching problem

[Jim Hyslop]

Jeff Bowes wrote:
> Hi,
>
> I am a newbie to CVS but already have a rather sticky CVS problem to 
> solve that seems like it would need several branches.  Here is our 
> situation.
>
> We receive some 3rd party open source software that is designed to run 
> on Postgres and we need to run it on DB2. However,  we also want to 
> maintain a version that will run on Postgres for purposes of 
> comparison.  We expect to get reasonably frequent updates from the 
> Vendor. Also, some changes to the code will need to be made that are 
> carried through on both the Postgres and DB2 versions of code.  (e.g.  
> adding some logging, some additional features).
>
> I have read the documentation of branching and documentation on using 
> Vendor tags. However, I don't quit know how to put it together to solve 
> this problem. I have not been able to find any examples of using 
> branching to maintain software versions designed to run on different 
> database platforms.
>
> Does anyone have any suggestions on how to set this up?

Your branching model does not need to be very complex.

What you've described boils down to a problem with portability. Branches 
are not the solution to portability. The portability problem is best 
solved by using distinct files (possibly in distinct subdirectories, 
depending on the complexity).

The CVS import command automatically creates a "vendor branch", which is 
where all the vendor-supplied files will go. You make your 
customizations on a different branch (probably the trunk). When the 
vendor supplies an update, just re-import it onto the vendor branch, and 
merge the changes from the branch to the trunk.

Make sure you keep your portability modifications distinct from the 
other changes you need to make. This may be a little more complex to set 
up initially, but it will vastly simplify your life in the long run.

Since the software is open source, you may want to consider submitting 
your portability changes as patches to the original source code. This 
will simplify things even more for you, since the vendor updates will 
already be portable and you only need to merge in your customized code 
(which, by the way, if it's useful in the general case, you may also 
want to consider submitting as a contribution to the open-source project 
;=).

--
Jim