You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Benson Margulies <bi...@gmail.com> on 2013/06/13 13:04:51 UTC
Where to aim a patch
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Michael McCandless <lu...@mikemccandless.com>.
4.4 is likely the next release, so use the 4.x branch:
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
Mike McCandless
http://blog.mikemccandless.com
On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies <bi...@gmail.com> 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Where to aim a patch
Posted by Uwe Schindler <uw...@thetaphi.de>.
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:lucene@mikemccandless.com]
> > 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 <yo...@lucidworks.com>
> > wrote:
> > > On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies
> > <bi...@gmail.com> 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: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Where to aim a patch
Posted by Uwe Schindler <uw...@thetaphi.de>.
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.
The other way round is in most cases not so easy to do, especially when trunk's APIs already changed.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> 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 <yo...@lucidworks.com>
> wrote:
> > On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies
> <bi...@gmail.com> 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: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Shawn Heisey <so...@elyograg.org>.
On 6/13/2013 9:56 AM, Michael McCandless wrote:
> On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
>> 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.
I've noticed that subversion 1.7 gets rid of the problem where tons of
completely unrelated files get property updates, but the commit after a
merge does still (correctly) touch more than the patched files.
It's cleaner to target trunk and then backport, but as Uwe just said,
there are sometimes legitimate reasons for going the other direction.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Benson Margulies <bi...@gmail.com>.
Folks,
I asked this question to direct my work on SOLR-4872. I am happy to make
patches for that work on as many branches as needed -- what I lack is a
community decision on the design decision raised on that JIRA.
Re: Where to aim a patch
Posted by Chris Hostetter <ho...@fucit.org>.
: One thing to think about is if you develop on trunk and forget to merge to
: 4.x, thats ok. the other way around is bad though, it basically creates an
: instant regression.
:
: So I'm a little worried about this. I think development should be against
: trunk!
+1 ... for me it's never been a question of the tools -- i've never
trusted the merge props to help keep anything straight. I'm first and
foremost concerned about features/fixes making it into 4x that then vanish
when 5x comes out.
Knowing that "logical commits" are only flow in one direction (even if the
physical bits being changed are different) is really helpful for keeping
sane ... particulaly when you start seeing test failures in 4x but not
trunk, or vice versa: The number of possible causes doubles when there's
a chance someone made a logical commit to 4x that never made it to trunk
(was a bug committed to X but not Y? was a fix committed to Y but not X?)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Jun 26, 2013 at 10:30 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> On Thu, Jun 13, 2013 at 11:56 AM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
> > On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <yo...@lucidworks.com>
> wrote:
> >
> >> 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.
>
> As far as I can tell it's fine from SVN's standpoint to merge 4.x ->
> trunk, at least using SVN 1.7.
>
> I just merged a few changes in that direction and I see no difference
> in the number of svn props changed, vs when I commit first to trunk
> and then merge to 4.x.
>
> So I think net/net we are free to work in whatever direction we
> prefer. We shouldn't let our source control tools dictate our dev.
>
>
One thing to think about is if you develop on trunk and forget to merge to
4.x, thats ok. the other way around is bad though, it basically creates an
instant regression.
So I'm a little worried about this. I think development should be against
trunk!
Re: Where to aim a patch
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Jun 13, 2013 at 11:56 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
>
>> 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.
As far as I can tell it's fine from SVN's standpoint to merge 4.x ->
trunk, at least using SVN 1.7.
I just merged a few changes in that direction and I see no difference
in the number of svn props changed, vs when I commit first to trunk
and then merge to 4.x.
So I think net/net we are free to work in whatever direction we
prefer. We shouldn't let our source control tools dictate our dev.
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies <bi...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Benson Margulies <bi...@gmail.com>.
Well, I'm hard at work on the 4x branch already, but I'll do the
adaptation to trunk when / if I get it working.
On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies <bi...@gmail.com> 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.
>
> You can point the JIRA issue at 4.4 however.
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Where to aim a patch
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies <bi...@gmail.com> 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.
You can point the JIRA issue at 4.4 however.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org