Started effort under - https://issues.apache.org/jira/browse/OFBIZ-8652
Thanks to Rohit Kaushal for taking care of this. It will take 4-5 days for testing. Thanks! Rishi Solanki Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com On Sat, Sep 17, 2016 at 2:11 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Personally I will go this way: I will add or changes lines without putting > semicolons. > > I'm in favour of bulk changing files, but I'd prefer by component or > webapp to ease reviews. > > Jacques > > > Le 16/09/2016 à 15:36, Rishi Solanki a écrit : > >> I was saying #2 as per the comment from Taher .... >> >> Quick Reference: >> >> One reply from Taher ... in the same thread. >> ========== >> >> Okay, given the priorities and work we have at the moment, I suggest we >> keep semicolons and use it as the standard unless someone volunteers to >> make a full switch. WDYT? >> ========== >> >> >> >> Rishi Solanki >> Manager, Enterprise Software Development >> HotWax Systems Pvt. Ltd. >> Direct: +91-9893287847 >> http://www.hotwaxsystems.com >> >> On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux < >> jacques.le.r...@les7arts.com> wrote: >> >> I guess you mean 2) by file, then it's OK with me. Though I'd no be >>> against having semicolon inconsistency in Groovy files, which was my >>> initial question. So no strong opinion about 2 here. >>> >>> Jacques >>> >>> >>> >>> Le 16/09/2016 à 11:31, Rishi Solanki a écrit : >>> >>> To summarize the overall conversation; >>>> 1) We have decided to bulk remove semicolons from groovy. >>>> 2) Until #1 is not complete, we would keep adding semicolon for >>>> consistency. >>>> >>>> >>>> >>>> >>>> Rishi Solanki >>>> Manager, Enterprise Software Development >>>> HotWax Systems Pvt. Ltd. >>>> Direct: +91-9893287847 >>>> http://www.hotwaxsystems.com >>>> >>>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux < >>>> jacques.le.r...@les7arts.com> wrote: >>>> >>>> Actually I was wrong on this. Thanks to Jacopo I noticed that both >>>> >>>>> Subclipse and Tortoise allow you to select a range of revisions when >>>>> you >>>>> look for annotations. >>>>> >>>>> So it's no longer an issue for me and we can bulk remove trailing >>>>> semicolons in Groovy files if we want. >>>>> >>>>> Sorry for the confusion >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Le 14/09/2016 à 04:42, Scott Gray a écrit : >>>>> >>>>> I don't particularly care one way or another if groovy files have a >>>>> >>>>>> semi-colon at the end. I don't even care about consistency because it >>>>>> is >>>>>> such a minor thing. >>>>>> >>>>>> I say remove them if they're on a line you happen to be editing, >>>>>> otherwise >>>>>> just leave them be. >>>>>> >>>>>> Regarding the annotations, there's plenty of ways to search commit >>>>>> logs >>>>>> and >>>>>> personally I've never found blame to be very useful. I don't think it >>>>>> should be a reason to block any future bulk S/R cleanups. We've had >>>>>> plenty >>>>>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, >>>>>> whitespace >>>>>> removal, etc.) and we should continue to do it to keep things clean. >>>>>> >>>>>> For searching diffs, before using git-svn I used to use: svn log -diff >>>>>> <path/to.file> and then use the search in the terminal to find the >>>>>> string >>>>>> I'm looking for. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 14 September 2016 at 07:33, Jacques Le Roux < >>>>>> jacques.le.r...@les7arts.com >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Le 13/09/2016 à 21:28, Jacques Le Roux a écrit : >>>>>>> >>>>>>> OK found that the same than in Subclipse also exists in TortoiseSVN >>>>>>> >>>>>>> But you need to use a command line (weird for a GUI), eg (from >>>>>>>> TortoiseSVN root folder) >>>>>>>> >>>>>>>> Actually wrong, simply pick a file in Windows file explorer using >>>>>>>> >>>>>>>> TortoiseSVN context menu, et voilà! >>>>>>> I confirm, totally comparable to Subclipse annotations >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>>>>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi >>>>>>> >>>>>>> z\applications\product\src\main\java\org\apache\ofbiz\ >>>>>>>> product\catalog\CatalogWorker.java" >>>>>>>> >>>>>>>> All is explained here https://tortoisesvn.net/docs/r >>>>>>>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics >>>>>>>> >>>>>>>> From the resulting UI (comparable to Subclipse) I guess changing >>>>>>>> all >>>>>>>> lines of a file will have the same effect. >>>>>>>> Even if indeed the annotations are not lost, they are very hard to >>>>>>>> use >>>>>>>> if >>>>>>>> you need to compare revision by revision. >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit : >>>>>>>> >>>>>>>> BTW thinking about it, don't you have something similar in IntellIJ? >>>>>>>> >>>>>>>> I found an (old) image there https://markphip.blogspot.fr/2 >>>>>>>>> 006/12/subclipse-live-annotations.html >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 13/09/2016 à 20:16, Jacques Le Roux a écrit : >>>>>>>>> >>>>>>>>> Thanks Jacopo, >>>>>>>>> >>>>>>>>> I found how to use it in TortoiseSVN (it starts from the log view) >>>>>>>>>> It's complementary to what Subclipse gives and so interesting but >>>>>>>>>> not >>>>>>>>>> comparable. >>>>>>>>>> >>>>>>>>>> You don't have this global view Subclipse offers with each >>>>>>>>>> annotation >>>>>>>>>> by line from start (r1) to HEAD. >>>>>>>>>> Very useful with colored annotations in the same column than lines >>>>>>>>>> numbers. But it unfortunately contains only the last revision if >>>>>>>>>> all >>>>>>>>>> lines >>>>>>>>>> have been modified together in that revision. >>>>>>>>>> Note: to see it you need to use "Show Quick Diff" ("Revision" and >>>>>>>>>> "Combined Colors" are then default options, hovering is enough for >>>>>>>>>> me). >>>>>>>>>> Same than you decide to show line numbers in this column... More >>>>>>>>>> for >>>>>>>>>> those who are still using Eclipse... >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit : >>>>>>>>>> >>>>>>>>>> Some examples: >>>>>>>>>> >>>>>>>>>> svn blame README.md >>>>>>>>>>> >>>>>>>>>>> after review you run >>>>>>>>>>> >>>>>>>>>>> svn blame README.md -r 1:1757044 >>>>>>>>>>> >>>>>>>>>>> and then >>>>>>>>>>> >>>>>>>>>>> svn blame README.md -r 1:1757042 >>>>>>>>>>> >>>>>>>>>>> and so on to get back in history... nothing is lost, annotations >>>>>>>>>>> are >>>>>>>>>>> always >>>>>>>>>>> there. >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> PS: I think there is some trick to do the same with TortoiseSVN >>>>>>>>>>> but I >>>>>>>>>>> can't >>>>>>>>>>> tell you the details since I don't use it >>>>>>>>>>> >>>>>>>>>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux < >>>>>>>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit : >>>>>>>>>>> >>>>>>>>>>> On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux < >>>>>>>>>>> >>>>>>>>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> Before applying a such change, I'd really like to know if >>>>>>>>>>>>> everybody >>>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>>>> aware of what that means when it comes to svn annotations. I >>>>>>>>>>>>>> repeat: we >>>>>>>>>>>>>> will then lose all the svn annotations history in all the >>>>>>>>>>>>>> Groovy >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacques, are you aware that you can pass the -r argument to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>> blame/annotate command? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacopo >>>>>>>>>>>>> >>>>>>>>>>>>> I must say I never use that when looking at annotations in a >>>>>>>>>>>>> file >>>>>>>>>>>>> in >>>>>>>>>>>>> >>>>>>>>>>>>> Eclipse. It's maybe useful in certain circumstances, but I >>>>>>>>>>>>> hardly >>>>>>>>>>>>> >>>>>>>>>>>>> see >>>>>>>>>>>> when. >>>>>>>>>>>> And once all the lines a file has been modified in one commit, I >>>>>>>>>>>> guess -r >>>>>>>>>>>> does not help at all, anyway you get only this information. Or >>>>>>>>>>>> do >>>>>>>>>>>> I >>>>>>>>>>>> miss >>>>>>>>>>>> something? Should I know the revision I'm looking for? I rather >>>>>>>>>>>> try >>>>>>>>>>>> to know >>>>>>>>>>>> when and why a line has been changed, what are the reasons of >>>>>>>>>>>> these >>>>>>>>>>>> changes, maybe to find an related Jira, etc. >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >
