MattyJ wrote: > 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.
The integrate-up operation is interesting. It sounds like that might offer the advantage of pre-testing prior to the merge-back-down, but I wonder if you ever find touchy situations where merge-up conflicts with the branch work. >.. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
