the problem is that the javahl libraries don't return the exact
timestamp. they knock off several digits from the timestamp returned by
the native client libaries. if you use the command
svn log --xml
at the command line, you get back the full timestamp. this timestamp can
be used accurately to retrieve the revision. so the timestamp is a
supported property that apparently accurately maps to a particular
revision.
the problem of the javahl libraries truncating the timestamp is distinct
from how any considerations about using the data. whether the timestamp
is an effective key is a different discussion.
cheers,
andy
> -----Original Message-----
> From: Dale Worley [mailto:dworley@pingtel.com]
> Sent: Tuesday, June 28, 2005 10:03 AM
>
> It seems to me that the fundamental problem is architectural
> -- You've settled on "time of the revision" as the universal
> identifier (key) for revisions, but Subversion explicitly
> considers the time of a revision to be just another property
> of the revision. (Other souce control systems may have
> similar policies.) You can't reliably put an interface that
> requires property X on top of software that does not require
> property X.
>
> Much more reliable, I think, would be for your system to
> define its own revision key datum, and for each real system
> that it is put on top of, map an appropriate feature of the
> real system into the revision key.
>
> Dale
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 21:02:52 2005