Nate Kerkhofs wrote on Fri, 29 Mar 2019 09:08 +00:00:
> Checking the tag revisions done yesterday through the other unit tests,
> all the dates of the revisions are monotonically increasing, with time
> between dates ranging from 2 seconds to 2 hours, but always increasing
> compared to the previous date. I'm not sure if any older revisions
> might be causing the issue, but I'm assuming that any commits that have
> been done a day or earlier before the issues occurred probably didn't
> cause it, because I assume they'd have triggered the issue earlier. I'm
> not sure about that last thing, but it seems logical.
I don't think that's right, actually. Suppose that revisions 0:100 have
monotonically-increasing dates, then somebody creates a revision with an
old date (r101), then somebody creates a normal r102, then development
goes on at a rate of one revision per day. Because of how binary search
works, the backdated r101 would have no effect on the resolution of "in
the distant past" dates for a long time (and even once it does fire, it
will afterwards go latent again, because of how the math works).
You probably have a large chunk of backdated revisions, not just one.
Try running these commands:
svn info --show-item=revision -r "{2008-01-01T00:00:00}" ^/
svn info --show-item=revision -r "{2019-02-20T10:21:03}" ^/
I think you might find that the first of these two commands gives a
revision number more recent than you'd expect, probably for the reasons
explained in Andreas's first reply.
> In case it could actually be one of the earlier revisions, are there
> any tricks or software I can use to test whether revisions are broken
> in this manner?
Iterate the revisions from 0 to HEAD and check if their svn:date values
are monotonically increasing. It's all of 10 lines of code in any
scripting language. (If you use 'propget svn:date' you won't even need
a date arithmetic library, because sorting ISO-8601 data as ASCII
strings sorts it chronologically.)
Cheers,
Daniel
P.S. (Humour detour: rfc2550)
