subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Kerkhofs <>
Subject RE: svn log -r based on a start date suddenly no longer returns any revisions
Date Mon, 01 Apr 2019 07:27:52 GMT

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,


-----Original Message-----
From: Daniel Shahaf <> 
Sent: vrijdag 29 maart 2019 15:20
To: Nate Kerkhofs <>
Cc: Andreas.Stieger <>;
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.)



P.S. (Humour detour: rfc2550)

View raw message