Daniel Shahaf <danie...@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.
> @@ -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.
> + ## 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?
> + 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.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
