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?
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?
Regards,
Blair
[[[
Allow the JavaHL bindings for log messages to get the original
apr_time_t value in microseconds since 00:00:00 January 1, 1970 UTC.
Currently, the java.util.Date object contains only the microseconds.
[all in subversion/bindings/javahl]
* src/org/tigris/subversion/javahl/LogMessage.java
(timeMicros):
New private long field.
(LogMessage):
Add an additional constructor that takes the commit time measured
in the number of microseconds since 00:00:00 January 1, 1970
UTC.
For the original constructor, populate the timeMicros from the
java.util.Date.getTime() method.
(getTimeMicros):
Returns the commit time measured in the number of microseconds
since 00:00:00 January 1, 1970.
(getTimeMillis):
Returns the commit time measured in the number of milliseconds
since 00:00:00 January 1, 1970.
* src/org/tigris/subversion/javahl/LogMessageCallback.java
(singleMessage):
Instead of taking a java.util.Date() as an argument, take a long
value with the number of milliseconds since 00:00:00 January 1,
1970. Users of the callback can always construct a new
java.util.Date if they need it.
* native/LogMessageCallback.cpp
(LogMessageCallback::singleMessage):
Look for the LogMessageCallback.singleMessage() with the long
argument instead of the java.util.Date argument.
Do not construct a java.util.Date here.
Pass the apr_time_t to LogMessageCallback.singleMessage().
* src/org/tigris/subversion/javahl/SVNClient.java
(MyLogMessageCallback.singleMessage):
Implement the new singleMessage interface.
Build a LogMessage using the microseconds time.
* src/org/tigris/subversion/javahl/tests/BasicTests.java
(testBasicLogMessage):
Test that the new methods that return the time in micro and
milliseconds compare identically with the java.util.Date.
]]]
---------------------------------------------------------------------
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:18:22 2007