Hi Grant, The individual merges are there since long time. And the additional ones came in later. As I said before (answer to first mail on this thread): The problem is that once a file gets a separate merge property not inherited from its parent folder, this merge prop must be updated on every later merge. So whenever you merge a file separately you create one more problem :-)
Some merges in trunk cannot be done completely top-level, but if they are always done in the same way, the number of files/subdirs with separate mergeprops is limited. One problem is the new modules folder as the analysis folder in it must be merged to contrib. Also the moved tokenstreams and analyzers. But all other touched files are results of one-file merges. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Grant Ingersoll [mailto:gsing...@apache.org] > Sent: Tuesday, October 19, 2010 9:30 PM > To: dev@lucene.apache.org > Subject: Re: possible to filter the output to commits@ list???? > > > On Oct 19, 2010, at 3:04 PM, Chris Hostetter wrote: > > > > > : FWIW, I get the sense that a lot of other projects deal with merges. What > do they do? > > > > I suspect they do merges properly and avoid this problem entirely. > > > > Bottom Line: if *all* merges happen at the top level, then this > > problem won't exist -- mergeinfo props get added to individual files > > only when individual file merges take place, or with merges from mixed > > working revisions. Once a file gets those merge props, all future > > merges in that tree interact with those individual file props even if > > the merge has nothing to do with those files... > > > > http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.b > > ranchmerge.advanced.finalword > > I will go take a look at it, but as far as I could tell, I merged at the top level, but > maybe IntelliJ does individual file merges and I wasn't aware of it (I believe I > said merge trunk to branch_3x and then picked which revisions I wanted to > apply). Perhaps we should put together some examples in Lucene's context > that would give Lucene developers a deeper understanding. > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
