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
Received on 2017-02-24 19:08:40 CET