Philip Martin wrote on Tue, Jul 09, 2013 at 10:12:35 +0100:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > Philip - would the following work on your machine? I'd be +1 on the
> > r1496127 nomination in STATUS if the following patch were (commited to
> > trunk and) added to it.
> >
> > In case it matters, the Python version I tested it with is 2.6.
>
> 2.5 is the problem and I don't have a machine with 2.5 installed.
>
I have access to a machine running:
Python 2.4.4 (#1, Jan 10 2007, 01:25:01) [C] on sunos5
> > @@ -666,10 +668,20 @@ def checkout_peg_rev_date(sbox):
> > sbox.repo_url)
> > if exit_code or errput != [] or len(output) != 1:
> > raise svntest.Failure("svn:date propget failed")
> > - r1_time = output[0]
> >
> > - # sleep till the next second.
> > - time.sleep(1.1)
>
> I think we still need a sleep to ensure that the two commits don't have
> the same svn:date on machines with limited internal time resolution.
> Perhaps 100ms? I expect all machines have much higher resolution
> internally but perhaps they don't all expose it.
>
http://docs.python.org/release/2.5.4/lib/module-time.html#l2h-2829 only
promises a resolution of 1 second. It's also documentation written in
1998, so take it for what it's worth.
Either a sleep(0.1) or just removing the time.sleep() call waiting for
somebody to report that it's broken for them would be fine by me.
> > + ## Increment the svn:date date by one microsecond.
> > + # TODO: pass tzinfo=UTC to datetime.datetime()
> > + date_pattern = re.compile(r'(\d+)-(\d+)-(\d+)T(\d\d):(\d\d):(\d\d)\.(\d+)Z$')
> > + r1_time = datetime.datetime(*map(int, date_pattern.match(output[0]).groups()))
> > + peg_time = r1_time + datetime.timedelta(microseconds=1)
>
> Does that work in 2.5?
>
It works in 2.4:
>>> r1_time = datetime.datetime(2007, 1, 10, 1, 25, 1, 123456)
>>> peg_time = r1_time + datetime.timedelta(microseconds=1)
>>> repr(peg_time)
'datetime.datetime(2007, 1, 10, 1, 25, 1, 123457)'
The documentation in 2.5.4 promises timedelta objects have microsecond
resolution.
> > + assert r1_time != peg_time
> > + # peg_string is, by all likelihood, younger than r1's svn:date and older than
> > + # r2's svn:date. It is also not equal to either of them, so we test the
> > + # binary search of svn:date values.
> > + peg_string = '%04d-%02d-%02dT%02d:%02d:%02d.%06dZ' % \
> > + tuple(getattr(peg_time, x)
> > + for x in ["year", "month", "day", "hour", "minute",
> > + "second", "microsecond"])
> >
> > # create a new revision
> > mu_path = os.path.join(wc_dir, 'A', 'mu')
> > @@ -691,7 +703,7 @@ def checkout_peg_rev_date(sbox):
> >
> > # use an old date to checkout, that way we're sure we get the first revision
> > svntest.actions.run_and_verify_checkout(sbox.repo_url +
> > - '@{' + r1_time + '}',
> > + '@{' + peg_string + '}',
> > checkout_target,
> > expected_output,
> > expected_wc)
>
> Why remove the exact test? It's not clear that testing only the unequal
> value is better than testing only the equal value.
Fair point. I suppose we should test both scenarios?
Received on 2013-07-09 15:52:55 CEST