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

Re: [PATCH] javahl using microsecond time in LogMessage

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-04-18 01:40:31 CEST

On 4/17/07, Blair Zajac <blair@orcaware.com> wrote:
> Working on a new Java Subversion project, I have a number of
> repositories that by design will have revisions that do not have
> monotonically increasing dates. So I'll be doing my own date to
> revision search through a log history.
> So I need two things, one is microseconds time since 1970 as stored in
> apr_time_t and I want to do the sorting fast. Currently, the
> java.util.Date's contain microsecond time since 1970, so the sorting
> algorithm may not be accurate if I truncate the times. Also, if I use
> new log message callback in trunk's SVNClient.logMessages(), then I can
> get the timestamp and with the attached patch, not have to construct
> java.util.Date's and only use the timestamp.
> The current LogMessage class grows an additional field, but besides
> calling the new constructor from the C++ code, will there be any
> ramifications of doing this?
> Is this a safe change to make? Will it break anything for older clients?

In my opinion, the change is safe.

> I know in C land, adding a field to a class or structure can be
> problematic, but in Java, will their be an issue?
> I need to add a new constructor, but I'm keeping the old one around and
> populating it from the timestamp in the java.util.Date, in case anybody
> calls it?

I am attaching a tweaked patch. Basically I just ditched the Date
field from the LogMessage class. There is no point in carrying it
around in the class when we can make it on the fly from the timeMicros
field. What do you think?

Mark Phippard

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed Apr 18 01:40:45 2007

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.