+1 On Nov 15, 2007 7:50 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> +1 on this clarification to my original post > > On 11/15/07, Matt Cooper <[EMAIL PROTECTED]> wrote: > > +1 to committers patching both "branches" as they go; no more poor > > soul having to do an ubermerge :) > > > > On Nov 15, 2007 5:38 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > > Jeanne, > > > > > > Yes they are saying different things but the two are not mutually > > > exclusive. What I was saying was +1 to creating a 1.2 trunk. > > > > > > That said, we will have to move to a situation where patches are > applied > > > to the main branch as a per-patch basis to make this manageable. > Matt's > > > concerns for creating this trunk are valid and can be addressed quite > > > easily by changing how we choose to apply changes. I think in the > long > > > run it'll make the 1.2 branch more stable because we will no longer > have > > > to depend on an UBERMERGE to get the code into the new branch. > Instead > > > issues can be addressed when the patches are applied and the committer > > > is familiar with the code. > > > > > > Scott :) > > > > > > > > > Jeanne Waldman wrote: > > > > What is Matt saying that is different than what Andrew was saying? > > > > We are going to require someone to check into both 1.2.X and 1.0.X, > > > > correct? > > > > This is a step in the right direction, and helps me out since I > won't > > > > have to do the merge if this goes through. > > > > > > > > +1 > > > > > > > > - Jeanne > > > > > > > > Scott O'Bryan wrote: > > > >> +1 to adding the trunk and I think Matt's suggestion is the best > way > > > >> to do this without being too cumbersome. > > > >> > > > >> Matt Cooper wrote: > > > >>> +0 I have had troubles with the reverse structure of having the > legacy > > > >>> code on the trunk and the latest in a branch so I would like that > to > > > >>> switch too. As Jeanne points out, I think having 2 trunks would > make > > > >>> merging more difficult--at least if the rules remained as noted in > > > >>> Adam's wiki. Now, if we were to apply patches as a one-by-one > basis > > > >>> and no no longer perform large trunk-to-branch style merging for > > > >>> releases then this would be a big win. This would help to prevent > > > >>> accidental merging of patches that are specific to a particular > > > >>> release into the wrong release. This may not be what the vote is > for > > > >>> so my vote is just neutral for now. > > > >>> > > > >>> Regards, > > > >>> Matt > > > >>> > > > >>> On Nov 15, 2007 12:09 PM, Martin Marinschek > > > >>> <[EMAIL PROTECTED]> wrote: > > > >>> > > > >>>> +1, > > > >>>> > > > >>>> regards, > > > >>>> > > > >>>> Martin > > > >>>> > > > >>>> > > > >>>> On 11/15/07, Grant Smith <[EMAIL PROTECTED]> wrote: > > > >>>> > > > >>>>> +1, Andrew's suggestions make good sense. > > > >>>>> > > > >>>>> On 11/15/07, Andrew Robinson <[EMAIL PROTECTED]> > wrote: > > > >>>>> > > > >>>>>> On 11/15/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote: > > > >>>>>> > > > >>>>>>> The same fix was in both, but one had different spacing. > > > >>>>>>> > > > >>>>>> Then it wasn't merged correctly and technically wasn't the same > fix > > > >>>>>> from a repository point of view. With two active versions, ppl. > > > >>>>>> would > > > >>>>>> be responsible for using svn commands for putting a change set > in > > > >>>>>> both > > > >>>>>> branches and not doing manual edits except for conflict > resolution. > > > >>>>>> > > > >>>>>> If ppl used the tool correctly, there should not be any such > > > >>>>>> conflicts. > > > >>>>>> > > > >>>>>> > > > >>>>>>> Check Adam's wiki about merging the branches > > > >>>>>>> > > > >>>>>> Yes, this is assuming the current procedure without an active > > > >>>>>> branch on > > > >>>>>> JSF 1.2 > > > >>>>>> > > > >>>>>> > > > >>>>>>> - Jeanne > > > >>>>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> Grant Smith > > > >>>>> > > > >>>>> > > > >>>> -- > > > >>>> > > > >>>> http://www.irian.at > > > >>>> > > > >>>> Your JSF powerhouse - > > > >>>> JSF Consulting, Development and > > > >>>> Courses in English and German > > > >>>> > > > >>>> Professional Support for Apache MyFaces > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >> > > > >> > > > > > > > > > > > > >
