Hi Rishi,
Will you commit as a whole?
Jacques
Le 28/10/2016 à 12:07, Rishi Solanki a écrit :
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
