+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 > > >>>> > > >>>> > > >>> > > >>> > > >> > > >> > > > > > > > >
