Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321514

Summary:

History View shows wrong dates for some checkins

Product:

[Technology] Subversive

Reporter:

Daniel Schneller <daniel.schneller>

Component:

Assignee:

Igor Burilo <igor.burilo>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

fhd

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Subversive History View	none
TortoiseSVN History View	none

Description Daniel Schneller

2010-08-02 10:55:55 EDT

Build Identifier: 20100218-1602

In the history view Subversive displays "funny" dates for some revisions. These look fine when viewed using e. g. TortoiseSVN or another SVN client.

It appears that when hitting "Refresh" in the history view, most of the time the problem goes away.

I have not looked at the code, but this might be an issue with a DateFormat instance being reused from multiple threads. This is not stable and can lead to completely wrong date displays. Some time ago I submitted a new detector for that to FindBugs. See the description here.
 http://findbugs.sourceforge.net/bugDescriptions.html#STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE

I will attach screenshots of the History view and the same range of revisions as shown by TortoiseSVN.

Reproducible: Sometimes

Steps to Reproduce:
1. Show history of a directory
2. Sometimes observe the problem
3. Hit Refresh in the history view toolbar to make it go away

Comment 1 Daniel Schneller

2010-08-02 10:56:21 EDT

Created attachment 175719 [details]
Subversive History View

Comment 2 Daniel Schneller

2010-08-02 10:56:40 EDT

Created attachment 175720 [details]
TortoiseSVN History View

Comment 3 Felix H. Dahlke

2011-03-22 07:25:03 EDT

We have also noticed these issues. The dates are in some cases from the future (e.g. 2020) and in some cases not displayed at all ("no date").

Comment 4 Alexander Gurov

2011-04-24 05:40:45 EDT

There were calls to the static instances in the SVN JavaHL API. So, now this unsafe code is avoided by copying reworked parts of the SVN JavaHL API implementation into the Subversive code. Hope it will solve the issue, because otherwise it will lead us into the depths of the SVN Client libraries implementation and we will be unable to do anything.