RE: How to manage oracle custom.pll libraries

[Andy Jones]

> Can you explain what you mean by enhancements A, B, and C?  If all of these
> new features:  A, B, and C are fairly independent but all modify the same
> files, then one approach would be to put each feature on its own branch.

But if you can make sure that the development for A, B and C does not 
happen at the same time, and know what order you need to develop them in, 
you don't *need* branches, do you?

Of course you might decide to have branches anyway, because that would 
allow you to fix bugs on A and develop on B at the same time.


> *  Keep your branches short -- the longer the branch the further away you
> are from the main branch, which means merging becomes more difficult.
> *  Create a tag each time you do a merge.  This could be a life saver if you
> have to make a second merge from a branch.
> *  Always merge changes back into the main branch, not the other way around.
> (This is real problem with the separate DEV, TEST, and PROD branches idea.
> You want to maintain as few of branches as possible).

I agree wholeheartedly. I would add:

* Before you create a branch, think very carefully.
    - Know exactly what the branch is for;
    - Know who's job it will be to merge it back;
    - Know when it will be merged back;
    - Allocate time for the merging process (including a system test of 
the merged code!).

In short, don't branch unless you are absolutely certain that you have to 
branch, and that you are ready for the consequences.