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