I do apologize for causing problems. But I do usually merge. However, if it is a trivial change (say, just a small test fix) it is a ton faster to just make the change to both branches instead of a merge. I guess I do not understand why this causes problems with seemingly unrelated code (I can be pretty sure the code involved with LUCENE-4585 is entirely separate than code I've been modifying). Is it really a bad thing to make a trivial change this way?
Perhaps the issue is when I do a merge, if I notice directories that have property changes only I omit them. Should I be including these? Often these are seeming random directories and I never quite understand why these are being included. (Maybe its just my ignorance of svn.) Perhaps this is the problem? James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, December 09, 2012 3:59 AM To: dev@lucene.apache.org Subject: RE: lost entries in trunk/lecene/CHANGES.txt Hi, I checked a little bit in the commit logs what was going on. From what I can reconstruct: - James Dyer did not use SVN merging to 4.x, he copied the whole file into the 4.x folder, this explains why the 5.0 changes entries suddenly appeared in the 4.x brach (which I removed yesterday). James seems to never merge his changes between branches, he applies patch several times or just copies files. - The commit where the entries got lost, that Doron restored an hour ago, seems to have copied an older version of the CHANGES.txt file over the newer version in SVN. This should be impossible with SVN, unless you “svn up” your current Working directory and fix the conflicts by telling SVN to use the older modified (“your”) version instead of doing 3-way-merge. One should use 3-way-merge to do this (e.g. with TortoiseSVN or Subclipse or by hand, arrgh ☺). It looks like James created the patch with an older SVN checkout but failed to merge the changes. James: Can you in the future please use “svn merge” (or the corresponding workflow in your GUI) to merge the changes between branches. This merge adds special “properties” to the SVN log, so one can find out which patches were merged between branches. E.g. TortoiseSVN or Subclipse show those in a different color in the commit log which helps immense if you are about to merge some changes. If you need some help with merging correctly, read http://wiki.apache.org/lucene-java/SvnMerge or just ask me. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de<http://www.thetaphi.de/> eMail: u...@thetaphi.de From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, December 09, 2012 10:15 AM To: dev@lucene.apache.org Subject: RE: lost entries in trunk/lecene/CHANGES.txt They were partly (but in a different way also missing in 4.x). I synced the part from version 4.1 down to version 0 with trunk. 3 entries were missing. Trunk now only has 5.0 as additional section, remaining stuff is identical. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de<http://www.thetaphi.de/> eMail: u...@thetaphi.de<mailto:u...@thetaphi.de> From: Doron Cohen [mailto:cdor...@gmail.com] Sent: Sunday, December 09, 2012 9:30 AM To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> Subject: lost entries in trunk/lecene/CHANGES.txt Hi, seems some entries were lost when committing LUCENE-4585 (Spatial PrefixTree based Strategies). http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/CHANGES.txt?r1=1418005&r2=1418006&pathrev=1418006&view=diff I think I'll just add them back... Doron
