-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SONARSCPER-4 Do not fail when a file has no blame information #7
Conversation
Properly skips unsubmitted files, allowing analysis to complete, but still got the The warning at the end of the analysis reported missing info for two files, one was my unsubmitted file and the other was submitted with only one revision. There is a Perforce bug (I won't go into detail) that results in the null date. The logs for it report |
@mjdetullio Thanks for testing. I'm a bit surprised of the failure on CE side since the message |
SQ 5.2, new project. On that note, an existing project in our production SQ 5.2 started failing with the Testing with a local SQ 5.3-RC2 instance, this PR, and as a new project, it now fails during analysis and not in CE. No apparent error message, even with Note that this file shows no issues when running the
|
This is giving me more trouble than I expected. There is no combination of The only way it's possible to get authors/dates for all revisions is to build a list of revisions from the annotate command and then get info for each of those revisions. What a nightmare. |
Hi all! @henryju sent me here in response to an issue I've been having with Perforce SCM since 5.2, which I've been discussing on the Google Group. I'm now running 5.3-RC2 and just pulled the perforce plugin snapshot (1.3-rc1). This is what I'm getting now when running the analysis (client side):
The error here is "Change 106385 unknown.". This changelist is from a different Perforce server (it was imported by branching from one linked server to another), so it can't be queried. The same goes for the prior one, 106336 -- this changelist happens to exist on both, but it's the WRONG CHANGELIST if you query it on this server! IT MUST NOT BE INCLUDED. When you were previously using p4 filelog, these changelists would have shown as being checked in by remote@remote (user@workspace), which tells you that it can be ignored. However when you're using just p4 annotate there's no way to know that, so you've now lost some information. Here's what the filelog looks like for this file the way that the 1.2 plugin runs it:
All of the changelists from remote@remote should be ignored. |
So then what's the best solution? Like I said, p4 filelog doesn't always Should p4 filelog still be used and then fall back to p4 change if the Because of SQ 5.2+'s requirement of date and author for each line, we need
|
In my opinion, SQ must not require a date and author for each line of code. Sometimes (like here, with imported source control data), that's simply not available. |
Alternatively, instead of p4 change -o ####, you could try p4 filelog -c ####, which would just return the filelog for that changelist. Hopefully in the case if imported changelists it will show remote@remote which will be sufficient information. |
Can you verify that functionality of
|
Sorry, filelog -c doesn't do what I thought it would do. |
I noticed that IntelliJ IDEA I can annotate the file I posted info about earlier, and it shows a username on every line, even though many of them are from imported revisions. It's displaying my own username; that could either because I was the one that imported it or because I'm the current user. I will investigate how it is doing this and get back to you. |
Based on what I'm seeing in IDEA, it looks like it's using |
You can use If you can rebuild from source with that change and report back results it would be useful. |
Good news! I pulled the branch |
By the way, the Perforce documentation says that |
Alright, I can live with that. |
Outstanding! Thanks @mjdetullio |
eaf34cb
to
ad0dbdb
Compare
ad0dbdb
to
94a528c
Compare
It is not possible to use a single invocation of p4 filelog to get revision data for all changelists returned by p4 annotate. To prevent invoking p4 filelog twice (once with -h and once without), retrieve data for each changelist number individually. To improve performance, changelists are stored in a map for later reuse.
Move P4JavaException to unchecked conversion to outer try block, allowing us to remove the inner try block and reduce complexity. The location of this conversion doesn't matter. Iterate file annotations only once. Add additional line annotation in test. Ensure server.getChangelist is invoked once to verify storing/retrieval from changelistMap works as intended. Add test for blame on last empty line.
94a528c
to
e96ca3c
Compare
No description provided.