[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sticky branching problem

From: Jim Hyslop
Subject: Re: Sticky branching problem
Date: Tue, 27 Sep 2005 08:56:14 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Jeff Bowes wrote:

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 ;=).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]