On Tue, May 10, 2011 at 6:10 PM, Richard Heck <rgh...@comcast.net> wrote:
> On 05/10/2011 11:27 AM, Vincent van Ravesteijn wrote: > > On Tue, May 10, 2011 at 3:21 PM, Richard Heck <rgh...@comcast.net> > wrote: > > > >> On 05/10/2011 08:50 AM, Abdelrazak Younes wrote: > >>> On 05/10/2011 02:12 PM, Richard Heck wrote: > >>>> On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote: > >>>>>> Third, when we switch to git, bugs will be fixed in branch first, > >>>>>> then these changes get merged into master automatically. > >>>>>> > >>>> This is a separate issue, but surely this isn't true. Bugs will get > >>>> fixed in git branches and merged into trunk, not fixed in BRANCH_2_0_X > >>>> (or whatever it is then called) and merged into trunk. > >>> Vincent meant that bugs should get fixed in git branches which were > >>> *branched* from BRANCH_2_0_X, not from master. Those branches would > >>> then get merged into BRANCH_2_0_X first and then (or at the same time) > >>> into master. > >>> > >> I'll have to think about this. The current policy of committing first to > >> trunk makes a lot of sense, as far as keeping branch stable. > > If we switch to git there is no such thing as committing to trunk first. > > > I understand this. I meant that ... > > >> There are > >> plenty of cases where a bug gets fixed in trunk first, and then we wait > >> to commit to branch until we see how that goes. > > > > In the development model I propose, we fix a bug in a topic branch. > > This branch will regularly be merged into a > > testing branch which is comparable to the current svn trunk. > > > ...what you describe here would happen, as opposed to their being > committed (merged) first to something comparable to current branch. > > > When a feature is cooked, tested, or if we have seen how it goes, the > feature > > will be merged either into master (a sort of stable trunk) or it will be > > merged into BRANCH_2_0_X. All fixes that are merged into > > BRANCH_2_0_X will of course get merged into the stable trunk > > as well when BRANCH_2_0_X get merged into master. > > > The only thing I would add to this is that I think the same distinctions > apply to BRANCH. Yes, you can create as many "snapshot branches" or "testing branches" as you want. In the end, the life of a commit is either: - commit in feature rgheck/dummy - merge rgheck/dummy into BRANCH_2_0_X - merge BRANCH_2_0_X into master or - commit in feature rgheck/dummy - merge rgheck/dummy into master Between the commit and final merge, the commit might be in one of those testing branches as long as it is needed. Vincent
