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