On Mon, 16 Jun 2008 01:09:55 -0700, Andrew Lentvorski <[EMAIL PROTECTED]>
wrote:
David Brown wrote:
On Sun, Jun 15, 2008 at 06:50:13PM -0700, Lan Barnes wrote:
But branching just because you want to check something in you don't
have
working yet makes little sense.
I think this philosophy must come from revision control systems that
make
branches expensive. With my git development, everything I checkin is
already on a branch. I can very cheaply create new branches. It is
typical to have several branches going at the same time, especially if
I'm
working on more than one idea at a time.
But, without free branches, it's probably hard to see just how useful
this
No, it's more about "what does a branch indicate?".
For me, a branch is something that is *not* going to get reintegrated
back into the main line later on in the future. And, Lan's examples
seem to be pointing in that same direction.
-a
I think it depends on the type of development you are doing and for what
purpose. I currently work for a financial services company. Our online
adiministration system is a live website that is constantly updated. It's
more of a continuum of changes rather than a series of mid-to-long-term
major releases.
We get small projects (1 week long or so) all the time that require
branches because the release schedule for said projects is not yet set.
They may sit there for another week before they go live and other smaller
things might go out in the meanitme. Sometimes these things do not get
released at all (I won't go into the issue of poor management, the reality
is that we have it and have to plan for it.)
We normally make branches then integrate the main line *up* into them. At
release time we do a sort of 'symbolic' merge back down just to help us
indicate later that this thing was released. If we do the up merge
correctly there is never any conflict. It also helps future integration
efforts if we need to re-open that branch for some reason. Note that we
use a source control tool that tracks the integrations.
In the world of agile, release streams are a smart thing. The whole point
is to do work without any regard to *when* something is going to be
released, only check in code that works, etc. Most of the discussion on
this thread so far seems to be in 'waterfall' mode, which is okay, but
there are certainly scenarios I can think of where small branches that are
not integrated back to main are needed, large branches that are intergated
back are needed, etc. Our open-ended policy on when to branch is 'branch
when needed', however, it's up to the CM group to evaluate the need and
make the actual branches. We veto plenty of branch requests every week.
-Matt
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
