Re: RE: svn log -r based on a start date suddenly no longer returns any revisions
On Mon, Apr 1, 2019 at 9:58 AM Andreas Stieger 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
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
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
Sent: vrijdag 29 maart 2019 15:20
To: Nate Kerkhofs
Cc: Andreas.Stieger ; 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
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
> 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
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
> > 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
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
Sent: donderdag 28 maart 2019 18:06
To: Nate Kerkhofs
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
> 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
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:
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
