You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nate Kerkhofs <Na...@ikan.be> on 2019/03/28 15:40:52 UTC
svn log -r based on a start date suddenly no longer returns any
revisions
Hi,
I have an issue with a subversion repository that suddenly, between 2 attempts roughly an hour or so apart, returns an empty xml list for the following command:
D:\vcrs\svn\Collabnet\bin\svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} --username username --password password http://testmachine:8110/svn/svn/UNITTEST/trunk --xml -v
The xml returned is:
<?xml version="1.0" encoding="UTF-8"?>
<log>
</log>
It should find exactly 2 commits in this range, because running svn log on the same directory without any revision filter and no --xml or -v arguments returns the following:
------------------------------------------------------------------------
r886 | (no author) | 2009-03-10 13:19:52 +0100 (di, 10 mrt 2009) | 1 line
deleted readme.txt
------------------------------------------------------------------------
r876 | (no author) | 2009-03-10 10:33:56 +0100 (di, 10 mrt 2009) | 1 line
added extra files and folders
------------------------------------------------------------------------
r3 | (no author) | 2005-11-10 15:38:33 +0100 (do, 10 nov 2005) | 1 line
------------------------------------------------------------------------
r1 | (no author) | 2005-11-10 15:32:07 +0100 (do, 10 nov 2005) | 1 line
Initial import of Subversion Unit Test project
------------------------------------------------------------------------
I had already created a stack overflow question on this issue at https://stackoverflow.com/questions/54784054/subversion-log-command-doesnt-show-the-most-recent-revision-from-almost-10-year, but with no answers afterwards. We originally had this problem late last month (around the 20th of February), and we ended up having to restore that repository from a backup. This issue suddenly returned today. Every other aspect of our unit tests works without issues on the same repository.
Passing along a revision number instead of a start date returns the expected result: if we replace the date in 2008 with a 3 indicating we want to get everything since revision 3, we get the expected result.
I tried this both with a Collabnet svn.exe of version 1.8.19, and an Apache Subversion 1.11.1 client. We have this issue on multiple machines, so it doesn't seem to be anything machine specific, and nothing has changed in that period apart from tags added through the unittests.
I'm not subscribed to the mailing list, and as such would like to be CC'd in any discussions regarding this issue.
Kind regards,
Nate
Re: RE: svn log -r based on a start date suddenly no longer returns
any revisions
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Apr 1, 2019 at 9:58 AM Andreas Stieger <An...@gmx.de> wrote:
>
> Nate Kerkhofs wrote:
> > [...] this repo does not have monotonically increasing dates [...]
>
> > The appropriate way to fix this would most likely be to simply create a new svn repository from scratch
>
> Actually you could set the svn:date revision property on the existing repository.
Another option (if you're considering rewriting the repository) is to
use svndumptool [1], with its 'merge' command.
(I haven't used it myself, just pointing it out, because I read the
readme of the tool)
[1] https://github.com/jwiegley/svndumptool
--
Johan
Aw: RE: svn log -r based on a start date suddenly no longer returns
any revisions
Posted by Andreas Stieger <An...@gmx.de>.
Nate Kerkhofs wrote:
> [...] this repo does not have monotonically increasing dates [...]
> The appropriate way to fix this would most likely be to simply create a new svn repository from scratch
Actually you could set the svn:date revision property on the existing repository.
Andreas
RE: svn log -r based on a start date suddenly no longer returns any
revisions
Posted by Nate Kerkhofs <Na...@ikan.be>.
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 <Na...@ikan.be>
Cc: Andreas.Stieger <An...@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)
Re: svn log -r based on a start date suddenly no longer returns any revisions
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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)
RE: RE: svn log -r based on a start date suddenly no longer returns
any revisions
Posted by Nate Kerkhofs <Na...@ikan.be>.
> I should have been more clear. You want to check the date. In other words, the svn:date property of a revision N must be later than the same of a revision M, for every N>M.
I see.
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.
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?
I'm still open to more suggestions, as before.
Nate
-----Original Message-----
From: Andreas Stieger <An...@gmx.de>
Sent: vrijdag 29 maart 2019 9:49
To: users@subversion.apache.org
Subject: Aw: RE: svn log -r based on a start date suddenly no longer returns any revisions
> > svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...] --xml -v
> > [..]
> > It should find exactly 2 commits in this range
>
> Check if all revisions (0:HEAD) on the root of the repository (not just trunk) are strictly monotonic increasing.
[...] counted the number of times the string "revision="
I should have been more clear. You want to check the date. In other words, the svn:date property of a revision N must be later than the same of a revision M, for every N>M.
Andreas
Aw: RE: svn log -r based on a start date suddenly no longer returns
any revisions
Posted by Andreas Stieger <An...@gmx.de>.
> > svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...] --xml -v
> > [..]
> > It should find exactly 2 commits in this range
>
> Check if all revisions (0:HEAD) on the root of the repository (not just trunk) are strictly monotonic increasing.
[...] counted the number of times the string "revision="
I should have been more clear. You want to check the date. In other words, the svn:date property of a revision N must be later than the same of a revision M, for every N>M.
Andreas
RE: svn log -r based on a start date suddenly no longer returns any
revisions
Posted by Nate Kerkhofs <Na...@ikan.be>.
Hi,
I've done an svn log on the root of the repository, wrote it to an XML log and counted the number of times the string "revision=" occurred in that log using Powershell. It returned 9246. This is also the number of the last revision in the log list, at the very bottom of the file. Is this enough evidence to assume they are strictly monotonically increasing? I'm not sure how else to do this considering this log has well over 9000 revisions.
I'm open to any more suggestions.
Nate
-----Original Message-----
From: Andreas Stieger <An...@gmx.de>
Sent: donderdag 28 maart 2019 18:06
To: Nate Kerkhofs <Na...@ikan.be>
Cc: users@subversion.apache.org
Subject: Aw: svn log -r based on a start date suddenly no longer returns any revisions
> svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...] --xml -v
> [..]
> It should find exactly 2 commits in this range
Check if all revisions (0:HEAD) on the root of the repository (not just trunk) are strictly monotonic increasing. If they are not, this can cause this issue. It is most frequently caused by importing repository history into a subtree of an existing repository.
Andreas
Aw: svn log -r based on a start date suddenly no longer returns any
revisions
Posted by Andreas Stieger <An...@gmx.de>.
> svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...] --xml -v
> [..]
> It should find exactly 2 commits in this range
Check if all revisions (0:HEAD) on the root of the repository (not just trunk) are strictly monotonic increasing. If they are not, this can cause this issue. It is most frequently caused by importing repository history into a subtree of an existing repository.
Andreas