RE: svn log -r based on a start date suddenly no longer returns any revisions

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.s_at_daniel.shahaf.name>
Sent: vrijdag 29 maart 2019 15:20
To: Nate Kerkhofs <Nate.Kerkhofs_at_ikan.be>
Cc: Andreas.Stieger <Andreas.Stieger_at_gmx.de>; users_at_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)
Received on 2019-04-01 09:28:14 CEST