[This was originally a response to maxb's commit of r13889.]
maxb@tigris.org writes:
> --- trunk/subversion/tests/clients/cmdline/revert_tests.py
> +++ trunk/subversion/tests/clients/cmdline/revert_tests.py
> @@ -113,6 +113,19 @@
> #
> # Any questions?
>
> + # Yes, I certainly do have questions.
> + # Why on earth do we *care*? Our usual policy is "Mess with .svn and bad
> + # things will happen". Why are we deviating in this case?
> + # Issue 1774 was filed seemingly out-of-the-blue, and there is no record in
> + # it of any discussion on whether it was a bug or not.
> + # I am setting this test to "Skip" for now.
> + #
> + # *If* we decide we want to actually do this, we should do it having
> + # discussed and settled on a design which does not introduce a
> + # crippling slowdown to "svn revert --recursive", as the r8984 did, by
> + # forcing every single text-base in the entire tree to be fully
> + # byte-for-byte compared AND checksummed.
> +
> sbox.build()
> wc_dir = sbox.wc_dir
> iota_path = os.path.join(wc_dir, "iota")
> @@ -207,7 +220,7 @@
> # list all tests here, starting with None:
> test_list = [ None,
> XFail(revert_reexpand_keyword),
> - revert_corrupted_text_base,
> + Skip(revert_corrupted_text_base),
> revert_replaced_file_without_props,
> ]
After thinking this over, and even starting a patch to restore the
corruption detection (but making it efficient), I think I've come
around to your point of view.
If no one disagrees, I'm happy to just remove the test, and annotate
issue #1774 appropriately.
Thoughts, anyone?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 4 18:23:10 2005