Hyrum K. Wright wrote:
>>> So a possible option c) would be to remove the timeMicros stuff
>>> altogether and just go back to having a Date. We can wait for Blair
>>> to comment. It seems to me that if the original goal was efficiency
>>> we definitely no longer have that.
>>
>> No, the goal was to not have lossy dates. I believe if you get the
>> date/timestamp from the 1.4 bindings for a revision and then lookup
>> the revision with it, the revision will be - 1 less then the original
>> revision, so its lossy.
>
> Does the command line client have this same problem? It would seem that
> all the date information is recoverable from svn:date. What part is
> being lost?
Yeah, I'm interested in this, too.
>> I think the best solution is to put back explicit parameters for all
>> our supported svn:* revprops and use the map for anything else. The
>> C++ code can easily remove the svn:date, svn:log and svn:author from
>> the map.
>
> True, that it's easy for the C++ code to filter out svn:* revprops, but
> I don't see why we should. Getting the property values from a Map isn't
> difficult, and it's much more extensible than passing values back
> directly. Also, I'd like to keep the JavaHL interface from drifting to
> far away from the C interface.
I don't use the Java bindings directly, but +1 on the sentiment of keeping
them from drifting unnecessarily from the C interface. I don't see how
returning svn:date's value asis would be "lossy". I mean, if it is, it
would seem we certainly couldn't remedy that client-side. Why not just keep
Hyrum's changes, but provide a handle utility function that converts
Subversion dates into timeMicros?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-05-22 17:19:55 CEST