Hi,
After running the first --show-item command, I have indeed found that this repo
does not have monotonically increasing dates: that first command returns
revision number 1311. Checking the svn log xml dump file I made, it appears
that r1153 is in 2010, and then r1154 is back in 2005, and then it starts
climbing from that again. It doesn't reach dates after the r1311 date until
1419.
The appropriate way to fix this would most likely be to simply create a new svn
repository from scratch, but could we in theory rewrite the revisions between
r1154 and r1419 (the revisions that are backdated), either through changing the
date to be properly monotonically increasing again or through deleting them
entirely? This repository is purely for unit tests, so having to create an
entirely new repository would create a lot of work.
Kind regards,
Nate
-----Original Message-----
From: Daniel Shahaf <d...@daniel.shahaf.name>
Sent: vrijdag 29 maart 2019 15:20
To: Nate Kerkhofs <nate.kerkh...@ikan.be>
Cc: Andreas.Stieger <andreas.stie...@gmx.de>; users@subversion.apache.org
Subject: Re: svn log -r based on a start date suddenly no longer returns any
revisions
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)
