Also in addition to what Jacopo suggested, depending on the context of what you are trying to do you can simply include an external script right at the end of build.gradle and externalize all your work in there. For example "echo apply from: 'my-script.gradle' >> build.gradle" or something like that.
On Aug 16, 2016 8:35 AM, "Jacopo Cappellato" < [email protected]> wrote: > If the time it takes you to resolve the conflicts due to local changes to > your build.gradle file is too much then you could automate your process by > preparing a script to revert your local changes before updating the trunk > and then re-applying them after the update: > 1) revert local changes (the script could also create a patch file with > your local modification before reverting them) > 2) update the trunk > 3) apply your local changes (e.g. by using the patch created in step #1) > > This should minimize the occurrences of conflicts, that could still happen > in step #3, and at the same time make it easier to deal with them (in step > #3). > > Hope it helps, > > Jacopo > > On Mon, Aug 15, 2016 at 8:32 PM, Pierre Smits <[email protected]> > wrote: > > > HI all, > > > > Over the past few weeks I am experiencing conflicts after an svn upgrade > > due to commits to build.gradle. These conflicts happen not only in my dev > > environment, but also in the various CIs I have testing against trunk. > Each > > time this happens I lose precious time to fix all this. > > > > Can we collaborate to get something in the code repo so that these > > conflicts won't happen again? > > > > Best regards, > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > >
