> I'm using subclipse with JavaHL 1.7.7. I am unclear is JavaHL keeps its > equivenence versioning the same as official svn versions? I do not have an > official svn command line installed, do not use tortise or other tools, etc. > > Reading Uwe's comment that I "never merge", I do wonder if its just that I > should let the directory property changes merge in also even if I do not
I did not say "you never merge", it appeared like that to me. The problems with CHANGES.txt are indeed strange to me, but you or your software restored an older version of CHANGES.txt. So it looked to me, like subclipse did not merge the changes correctly (when svn up). > understand them. I just don't like to commit stuff that seems unrelated to > what I'm doing and I don't understand. This fits because if it appears I > "never > merge", I also "always" omit seemingly unrelated property changes when > committing a merge. Keep them! The unrelated property changes are caused by the fact that properties cannot be "inherited". Once a directory has a merge property (caused by a previous commit), this merge property must be updated by later commits - causing unrelated property changes on merges. This gets worse when people do commits on single files. We sometimes clean up the merge properties, but you should keep all property changes done automatically during merging. If you omit them on unrelated directories/files, those appear as not merged to Subversion, causing confusion, especially when people merge later (e.g. the CHANGES.txt problems could be related to this, because CHANGES.txt has one of those extra properties). We don't list property changes in commit messages on ML, so it don’t hurts to commit them. > I also would like an answer to my question: "Is it ok to make parallel changes > instead of a merge if its just a trivial change?" Follow up question: "is > it ok to > make the same (trivial) change to 2 branches with 1 commit?" It really is > very > slow for me to merge and if the way I've handled trivial changes in the past > breaks things for other people, I can change my ways, or just not fix tiny > things if time doesn't allow. > Especially when I get an unexpected jenkins test failure, I'm usually in the > middle of something else and really want to fix jenkins asap but can't always > give it a lot of time (getting more coffee, as you might say to do, Robert) > while waiting for svn, etc. > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Monday, December 10, 2012 9:57 AM > To: dev@lucene.apache.org > Subject: Re: lost entries in trunk/lecene/CHANGES.txt > > On Mon, Dec 10, 2012 at 10:53 AM, Dyer, James > <james.d...@ingramcontent.com> wrote: > > > 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? > > > > Are you using svn 1.7? I really recommend this! > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
