That's pretty much how do it; it try an update and if it seems "very" broken, I just get a fresh copy of the trunk and apply the patch. Less than ideal since it's trial & error though but can't think of anything better.
I'm might backport to 1.2 instead and continue work on 1.3 with less constraints, this would give everyone more time; if I were to do so, would it be better to base on 1.2.dev or 1.2.1 branch? Henrib hossman_lucene wrote: > > > : Do you have any recommendation to ease keeping the patch 'up to date' > with > : the trunk? > > One trick i've seen people talk about but haven't had much experience with > myself is that if a patch made by "svn diff" doesn't apply cleanly with > the truck because of subsequent changes, grep the patch for the svn > reviewion that the patch is based on, run 'svn update -r ####" to revert > your working copy to that verion, apply the patch, then run "svn update" > to get back to the head ... "they" say that sometimes hte incrimental > nature of "svn udpate" can rectify the changes better then patch (since > patch only knows what the current version looks like) > > i tried it once with a patch that didn't apply cleanly and it worked well, > (but one test is not a solid foundation to judge as a general rule) > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Multiple-indexes-cores-%28aka-solr-215%29-functional-value--tf3927076.html#a11202451 Sent from the Solr - Dev mailing list archive at Nabble.com.
