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.
On Fri, Feb 24, 2017 at 10:08 AM, Dane Kantner <dane.kant...@gmail.com>
wrote:
> 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
>
