Hi, I forgot to explain *why*: > There are also legitimate use case for merging 4.x to trunk: > If you are working on deprecating stuff and replacing my new apis, you need > to often spend lot of work in "sophisticated backwards" :-) To do this > development, 4.x is the right place. I finally merge the stuff up to trunk and > then remove the deprecations.
This saves one commit! Otherwise you would develop the deprecations in trunk, commit them, backport to 4.x and commit again and finally remove in trunk and commit to trunk a second time. In this case developing on 4.x saves the second trunk commit and a temporary introduction of deprecations in trunk. Because you merge from 4.x to trunk with all deprecation changes and then remove those before committing. Uwe > > > -----Original Message----- > > From: Michael McCandless [mailto:[email protected]] > > Sent: Thursday, June 13, 2013 5:57 PM > > To: Lucene/Solr dev > > Subject: Re: Where to aim a patch > > > > On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <[email protected]> > > wrote: > > > On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies > > <[email protected]> wrote: > > >> I'd like to take a run at SOLR-4872 with the goal of getting it > > >> into the smallest-numbered release possible. What branch to I start on? > > > > > > IMO, patches should normally be aimed at trunk and backported. > > > "svn merge" tends to make a mess of the target (mergeproperties > > > updated so you can't tell at a glance what files a patch actually > > > changed), and in general we've tried to keep trunk clean by merging > > > from trunk instead of to trunk. > > > > Is this really true anymore, with latest svn clients (1.7.x)? > > > > I had always assumed devs are free to merge in either direction ... > > whatever their preference is. > > > > Mike McCandless > > > > http://blog.mikemccandless.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
