I'm using subclipse and subversive, and its def using a version above 1.7 - I have for a long time and sometimes I know I've chosen 1.8+ (I have a lot of eclipse installs).
Still, sometimes I have to merge a million props that are unrelated - sometimes I don't. I don't know what makes the difference. I have not used 1.6 in a long long time. - Mark On Mon, Dec 10, 2012 at 11:43 AM, Uwe Schindler <u...@thetaphi.de> wrote: >> 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 > -- - Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
