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" <eric_at_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.
On Fri, Feb 24, 2017 at 10:08 AM, Dane Kantner <dane.kantner_at_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
>
Received on 2017-02-25 00:42:22 CET