On Sun, 10 Sep 2006, glasser@tigris.org wrote:
...
> Test for Issue #2608, which appears to be a failure to stop
> conflicting dirprop commits on the root of repository from being
> committed, under FSFS.
>
> * subversion/tests/cmdline/prop_tests.py
> (commit_conflict_dirprops): New test.
> (is_this_fsfs): New function, telling if the fs type is
> FSFS. (Assumes that FSFS is the default, ick.)
> (test_list): Add new test, XFailing under fsfs.
...
> --- trunk/subversion/tests/cmdline/prop_tests.py (original)
> +++ trunk/subversion/tests/cmdline/prop_tests.py Sun Sep 10 13:09:57 2006
...
> @@ -1193,6 +1220,9 @@
> ########################################################################
> # Run the tests
>
> +def is_this_fsfs():
> + # This assumes that fsfs is the default fs implementation.
> + return (svntest.main.fs_type == 'fsfs' or svntest.main.fs_type is None)
>
> # list all tests here, starting with None:
> test_list = [ None,
> @@ -1202,6 +1232,7 @@
> downdate_props,
> remove_props,
> update_conflict_props,
> + XFail(commit_conflict_dirprops, is_this_fsfs),
> commit_replacement_props,
> revert_replacement_props,
> inappropriate_props,
The is_this_fsfs() API would be better off housed in the svntest.main
module. Even with only one consumer ATM, housing it there reduces the
opportunity for it to be re-implemented in another test script. How
about naming it is_fs_type_fsfs() or fs_type_fsfs_p()?
- application/pgp-signature attachment: stored
Received on Mon Sep 11 19:37:29 2006