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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >
