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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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.

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 
Reply | Threaded
Open this post in threaded view
|

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

Eric Johnson-35
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 <[hidden email]> 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 

Reply | Threaded
Open this post in threaded view
|

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

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?

Thanks


On Feb 24, 2017 5:24 PM, "Eric Johnson" <[hidden email]> 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 <[hidden email]> 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 


Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-5
Dane Kantner wrote on Fri, Feb 24, 2017 at 17:42:15 -0600:

> 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