John Peacock wrote:
>> -1 on changing the way we store timestamps or the search algorithm,
>
>
> Is that a hard veto or a "we haven't discussed this sufficiently yet"
> veto of what Sussman suggested? Would you have less argument with
> something that resolved some subsecond precision but abandoned the
> fiction of the current scheme (I'm thinking precision to 100ths of a
> second)?
It is a veto of this suggestion. See Michael Sinz's comments in another
response, they're relevant, and I agree with them.
This bug isn't so nasty that we have to hurry with a half-assed solution
that will scew us until 2.0. We can change the (i.e., invent an new)
server API that can be told something about the precision of the
timestamp, and we can enhance the date parser on the client to infer
that precision. We can release such API changes in any minor release.
But if we change the way the rimestamps are represented in the
repository, or worse, change the search algorithm, we're stuch with that
until 2.0 -- *and* we don't gain a thing because the results still won't
be correct if you get more than one commit within the timestamp's
precision interval.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 31 22:30:37 2005