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?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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