[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question on JavaHL change

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 23 May 2008 08:55:20 -0400

On Fri, May 23, 2008 at 2:35 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>> Looking more closely at the code:
>> 1) Only the java.util.Date is lossy, it only represents times to the
>> millisecond, so I put in the extra methods in LogMessage so you can get the
>> time in micros without doing any extra work.
> Would it be possible to have a LogDate class which extends java.util.Date
> (and can therefore be passed around as such), but which isn't lossy?

This sounds like a great idea. Make a LogDate class that you get from
the Map when you ask for svn:date. Internally, this class could just
store the timeMicros as a long and then have getter methods for
getting the date as a long, Date or String.

The point about LogMessage being deprecated is good. I had also
forgotten that we ask for the revprops we want. So I think all of
your comments make sense. My concern was just the current code
passing the date as a String, which is then parsed to a Date so that
we can turn it into a long and then the consumers of LogMessage have
all of that happen in reverse. It is ugly.

The LogDate idea is a good solution. Do we think we can get it
implemented in time for the release? If not, I still think we should
just back out these changes and do this in 1.6.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-23 14:55:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.