SVN log --revision "{2017-02-23T18:53Z}:{2017-02-24T02:46:15.225107Z}" not parsing date correctly?

Discussion:

Dane Kantner

2017-02-24 18:08:29 UTC

I'm running a script on a scheduled basis where each new iteration I'm
essentially checking against a newer time from the last check-in, so if the
last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
ticks to that after that in terms of the revision to retrieve everything
after that last check-in time via the svn log command. Generally this is
working great, but the actual results from the command aren't always
consistent. Sometimes the return results will include stuff that's
obviously before the provided start date. I initially was adding ticks,
then I added a second, and now even in the below command I'm getting
inconsistent results whereby it's returning something that's a full 20
minutes before the command inputted... So I'm at a loss--is this a parsing
error, is this date not really compliant (I believe it is...), etc.? I've
tried consolidating the date format to just 2017-02-23T18:52Z etc as well
and it doesn't matter.

The exactly command (slightly redacted here) I'm running is:

svn.exe log --non-interactive --trust-server-cert --username "****"
--password "*****" --revision
"{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}" --verbose --xml
"https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48"
"DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"

and the resultant XML is:
returning two items within that, the first of which should be there and one
which is before the provided time:

<?xml version="1.0" encoding="UTF-8"?>
<log>
<logentry
revision="54437">
<author>oooy</author>
<date>2017-02-23T18:51:15.175583Z</date>
<paths>
<path
action="M"
prop-mods="true"
text-mods="false"
kind="dir">/branches/SynergyR1.48/DOTNET/A/Synergy</path>
...
<logentry
revision="54442">
<author>oooyb</author>
<date>2017-02-24T02:46:15.225107Z</date>

I've been manually running this command from windows on multiple machines
w/ same result. I have latest tortoise client on at least 2 of the machines
but SVN server itself is version 1.8.11r1643975. I don't see anything too
obvious in the change log since that seems relevant to this though if it
were a bug.

So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
start time and the very specific point in start time at which it goes from
including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
to: {2017-02-23T19:06:02.41248Z} ... That's roughly shy of exactly 15
minutes after the actual checked time time. What is going on here w/ this
parsing? Again to clarify though even the simpler format
{2017-02-23T18:53Z} fails to properly parse as that includes the check-in
when it shouldn't. I've also tried a simple end date/time and that doesn't
affect the results.

Anyone have any suggestions or what to try to track this down? Given the
time

Eric Johnson

2017-02-24 23:24:25 UTC

Permalink

That's an interesting one.

I don't know why you're seeing the behavior you're seeing. However, I can
tell you that relying on the date is probably a mistake. Instead, better to
capture the revision # for the repository, and log for revision #s after
the last one you got. There are scenarios in which the svn:date information
recorded with a revision need not appear in strict chronological order.
I've run into this after combining repositories with svn:load.

Also it is possible to either change an svn:date property (svnadmin propset
...), or remove it altogether. In other words, depending on what you allow
of the repository clients, the date is not a reliable indicator of "changed
since".

Eric.

Post by Dane Kantner
I'm running a script on a scheduled basis where each new iteration I'm
essentially checking against a newer time from the last check-in, so if the
last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
ticks to that after that in terms of the revision to retrieve everything
after that last check-in time via the svn log command. Generally this is
working great, but the actual results from the command aren't always
consistent. Sometimes the return results will include stuff that's
obviously before the provided start date. I initially was adding ticks,
then I added a second, and now even in the below command I'm getting
inconsistent results whereby it's returning something that's a full 20
minutes before the command inputted... So I'm at a loss--is this a parsing
error, is this date not really compliant (I believe it is...), etc.? I've
tried consolidating the date format to just 2017-02-23T18:52Z etc as well
and it doesn't matter.
svn.exe log --non-interactive --trust-server-cert --username "****"
--password "*****" --revision "{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}"
--verbose --xml
"https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48"
"DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"
returning two items within that, the first of which should be there and
<?xml version="1.0" encoding="UTF-8"?>
<log>
<logentry
revision="54437">
<author>oooy</author>
<date>2017-02-23T18:51:15.175583Z</date>
<paths>
<path
action="M"
prop-mods="true"
text-mods="false"
kind="dir">/branches/SynergyR1.48/DOTNET/A/Synergy</path>
...
<logentry
revision="54442">
<author>oooyb</author>
<date>2017-02-24T02:46:15.225107Z</date>
I've been manually running this command from windows on multiple machines
w/ same result. I have latest tortoise client on at least 2 of the machines
but SVN server itself is version 1.8.11r1643975. I don't see anything too
obvious in the change log since that seems relevant to this though if it
were a bug.
So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
start time and the very specific point in start time at which it goes from
including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
to: {2017-02-23T19:06:02.41248Z} ... That's roughly shy of exactly 15
minutes after the actual checked time time. What is going on here w/ this
parsing? Again to clarify though even the simpler format
{2017-02-23T18:53Z} fails to properly parse as that includes the check-in
when it shouldn't. I've also tried a simple end date/time and that doesn't
affect the results.
Anyone have any suggestions or what to try to track this down? Given the
time

Dane Kantner

2017-02-24 23:42:15 UTC

Permalink

True except in my environment those are non issue as we control it pretty
tightly with process (and I would assume most professional development
shops are under similar constraints?). I actually started with revision
numbers but I wanted to specifically use the date time and not revision
number for modularity of then also having the functionality to pull by date
time specifically in script. But I suppose I can go the route of using
revision number in the same function but also build a wrapper for that
other functionality to determine revision number at the time based on
provided date time.

But nonetheless it seems like if the revision date range functionality is
going to be there it should work?

Thanks

On Feb 24, 2017 5:24 PM, "Eric Johnson" <***@tibco.com> wrote:

That's an interesting one.

I don't know why you're seeing the behavior you're seeing. However, I can
tell you that relying on the date is probably a mistake. Instead, better to
capture the revision # for the repository, and log for revision #s after
the last one you got. There are scenarios in which the svn:date information
recorded with a revision need not appear in strict chronological order.
I've run into this after combining repositories with svn:load.

Also it is possible to either change an svn:date property (svnadmin propset
...), or remove it altogether. In other words, depending on what you allow
of the repository clients, the date is not a reliable indicator of "changed
since".

Eric.

Daniel Shahaf

2017-02-25 08:20:08 UTC

Permalink

Post by Dane Kantner
True except in my environment those are non issue as we control it pretty
tightly with process (and I would assume most professional development
shops are under similar constraints?). I actually started with revision
numbers but I wanted to specifically use the date time and not revision
number for modularity of then also having the functionality to pull by date
time specifically in script. But I suppose I can go the route of using
revision number in the same function but also build a wrapper for that
other functionality to determine revision number at the time based on
provided date time.
But nonetheless it seems like if the revision date range functionality is
going to be there it should work?

The «-r {DATE}» functionality is implemented by a server-side binary
search on svn:date values, so it misbehaves when the svn:date across the
entire history (of the whole repository, not just the target path) are
not in ascending order.

That's a known issue. It usually happens due to dump/load into an
existing repository.

Cheers,

Daniel