[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Wed, 21 May 2008 22:36:57 -0700

Mark Phippard wrote:
> I have a question on recent JavaHL change merged to 1.5.x branch.
> In the logMessageCallback we now return a Map of revprops instead of
> the individual revprops. svn:date is returned as the date value.
> This forces us to add code like the following to get the timeMicros:
> // Really hacky date parser, because Java doesn't support
> // microseconds natively.
> try {
> DateFormat formatter = new SimpleDateFormat(
> "yyyy-MM-dd'T'HH:mm:ss.SSS");
> String datestr = ((String) revprops.get("svn:date"));
> Date date = formatter.parse(datestr.substring(0, 23));
> Calendar cal = Calendar.getInstance();
> cal.setTime(date);
> timeMicros = cal.getTimeInMillis();
> timeMicros = timeMicros * 1000
> + Integer.parseInt(datestr.substring(23, 26));
> I thought the timeMicros were only added in 1.5 to be a more efficient
> way to pass the date along. Or perhaps it was the extra precision.
> Either way, the efficiency and precision are both gone now. It seems
> like we should either:
> a) pass the timeMicros as an explicit parameter to the callback
> b) store it in the revprops. Either as the value of svn:date or as a
> made up revprop like svn:timemicros.
> c) forget it altogether and just pass along the date as is

I don't recall when timeMicros was added (but the fact that I needed to
parse the svn:date property for compat probably means it wasn't in 1.5).
  As for your suggestions, I'm opposed to a) on the grounds that we
shouldn't be treating svn:date as special in this callback. We could do
something like b) relatively easy (though I'd prefer to do it as an
additional property, not as svn:date). c) would be easiest, and ideal
if it still provides consumers what they need.


Received on 2008-05-22 07:37:15 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.