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