Re: two Modules, branch one module, or what?

[Pierre Asselin]

address@hidden writes:

>We have a development model where lots of "absolutely necessary" additions
>to our in house product are made daily.  So, we release a "stable build"
>several times a day.  Since these new features are added in this way, it
>would seem that the typical stable/development branch solution would not
>best suit our needs.

Typical what?  CVS doesn't work well with long-lived parallel
branches, I don't know anyone that has a stable branch and a
development branch like that.

One solution is to do the development on the trunk, which is never
stable.  When the trunk has enough "absolutely necessary" features
to ship something, you 1) tag it, 2) start a quality-assurance branch,
3) check out the QA branch somewhere else.

You then build the QA sandboxes and make sure the product doesn't
crash, fixing it if it does.  Then you put the product through its
paces and fix the less obvious bugs.  Then you can start shipping
releases off that branch and merging its bugfixes to the trunk.
The QA branch becomes a production/support branch.

Meanwhile, the trunk is as wild as ever and picks up one absolutely
necessary feature after another.  When the QA/prod/support branch is
hopelessly behind, you abandon it and start a fresh one off the trunk.

If all those absolutely necessary features are really absolutely
necessary, it follows that you're never ready to ship and you don't
even need a "stable branch"   !!


>This is because one would typically let stable sit
>for quite a while and acquire only fixes if I understand correctly.

Sort of what I said, except that my "stable" branch dies after a short
while.


>All
>the while, one would add all "enhancements" to the development branch and
>then merge the two at some point when development becomes stable again.

You don't merge two branches, not with CVS.  You merge *from* one
branch *to* another, usually to the trunk.  In the case I describe,
you merge bugfixes to the trunk, because it would be silly to go
through that QA work again for the same bugs.


>Since there is usually a large gap of time involved between stable
>releases, this is not the option we need.

The time lag is yours to choose.  Since your development is so
active, you can't really have a "stable branch" yet, your product
isn't mature enough.  But you should still test what you ship.


>Instead, something where
>development code could be checked in and flagged as development would be
>nice.  Then one could build development or production and get different
>products depending on the build flag.  Unless I overlooked it, CVS does not
>support this.

It supports another model, where all development is done on branches
and the trunk is used for integration and bug fixes.  Suppose the
trunk is in good shape, but you have three major feature sets to
work on, starting right now.  Tag the trunk (tag T0) and start three
branches A, B, C, from that point.  Start development of each
feature set independently on its branch.  If you have the staff,
work can progress more rapidly because the branches don't interfere
with one another --but this is just delaying the day of reckoning.
Your hope is that each branch *matures* faster than it would have
in the presence of the other changes.

Let's say branch A is ready for prime time.  You merge it to the trunk
by going to an up-to-date trunk sandbox and doing "cvs update -j T0 -j A".
There will be a few conflicts because the trunk has moved a bit since
tag T0, but it shouldn't be too bad.  Fix them and make sure the new
product works.  Oh, and *close branch A*.  It has served its purpose.

Now branch B is ready.  Same deal, "cvs update -j T0 -j B".  This time,
expect real conflicts.  This is the day of reckoning, you're using
your trunk for integration.  Deal with it and get your trunk fixed.

Meanwhile, branch C has slipped and it's already time to start
branches E, F and G for more major work.  Assume you don't want to
cancel project C.  You could leave C where it is, but you risk
having a very difficult merge when it is finally ready.  I would
"refresh" it as follows:

  * Tag the trunk, tag T1.
  * Start branches E, F, G off of T1 and start work on them.
  * Also start a branch C1 off of T1, and merge the incomplete branch
    C to the new branch C1, not the trunk.
        cvs update -r C1        : now on branch C1, still == T1
        cvs update -j T0 -j C   : the merge, conflict city

Now work furiously on branch C1 to resolve the conflicts and get
something that builds.  Commit on C1 and *close C*.

At this point, you have
  * The trunk, tag T1, relatively stable and with successful
    integration of branches A and B.
  * Development branches D, E and F for new feature sets.
  * A development branch C1 for the feature set that slipped.

Repeat, and hope this doesn't get out of hand.  I think this is
harder to do than the unstable-trunk model, but it can pay off in
productivity if you have a large staff with strong leaders, and if
you can partition your development into independent feature sets.


>So, it would seem that the only hack for this would be to
>have two parallel modules.  One would have development code and the other
>would be stable.  If at any point in time a piece of code became stable, a
>script could move it into the stable module.  In the end, this sounds just
>like branching except that it can be merged slowly piece by piece.

Consensus seems to be: "Ack! don't go there!"

Maybe the second model above is a good enough approximation to what
you want?  But I repeat:  it's harder to do.

--
Pierre Asselin
Westminster, Colorado


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----