Re: svn commit: r26009 - trunk/subversion/tests/cmdline

[Karl Fogel <kf...@red-bean.com>]

kameshj@tigris.org writes:
> Log:
> Follow-up to r22257.
>
> Add 'switch_with_obstructing_local_adds' test to the 'test_list'.
>
>  * subversion/tests/cmdline/switch_tests.py
>    (test_list): Add 'switch_with_obstructing_local_adds' to test_list
>
> Patch by: Senthil Kumaran <se...@collab.net>
>
> --- trunk/subversion/tests/cmdline/switch_tests.py	(original)
> +++ trunk/subversion/tests/cmdline/switch_tests.py	Thu Aug  9 04:17:28 2007
> @@ -1715,6 +1715,7 @@
>                XFail(relocate_and_propset, svntest.main.is_ra_type_dav),
>                forced_switch,
>                forced_switch_failures,
> +              switch_with_obstructing_local_adds,
>                switch_scheduled_add,
>                mergeinfo_switch_elision,
>               ]

I think it might be good to always add new tests to the end of the
list.  That way if there is an email thread referring "test 17" in
foo_tests.py, we will not affect the numbering and confuse that
thread.

Of course, in theory, we should always refer to tests by name anyway,
but sometimes people get careless.  If there's no reason to add a test
to the middle of the list, the end seems like the best place to me.

Thoughts?

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26009 - trunk/subversion/tests/cmdline

[Karl Fogel <kf...@red-bean.com>]

Senthil Kumaran S <se...@collab.net> writes:
> I added the test in the middle because that was the order in which the
> definition of the test occurs in the main code. Since it was missed
> out in the test list we have other tests appended to the list. Hence I
> thought instead of changing the definition order of the test in the
> code and appending the test to list, I can preserve the order of
> occurrence by adding it to the appropriate place in the list.

Well, remember, it's not actually necessary for the order of the tests
in the code to match their order in the test_list...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26009 - trunk/subversion/tests/cmdline

[Senthil Kumaran S <se...@collab.net>]

Hi Karl,

Karl Fogel wrote:
> I think it might be good to always add new tests to the end of the
> list.  That way if there is an email thread referring "test 17" in
> foo_tests.py, we will not affect the numbering and confuse that
> thread.

I added the test in the middle because that was the order in which the 
definition of the test occurs in the main code. Since it was missed out 
in the test list we have other tests appended to the list. Hence I 
thought instead of changing the definition order of the test in the code 
and appending the test to list, I can preserve the order of occurrence 
by adding it to the appropriate place in the list.

Thank You.

--
Senthil Kumaran S
http://www.stylesen.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r26009 - trunk/subversion/tests/cmdline

[Kamesh Jayachandran <ka...@collab.net>]

>>                forced_switch_failures,
>> +              switch_with_obstructing_local_adds,
>>                switch_scheduled_add,
>>                mergeinfo_switch_elision,
>>               ]
>>     
>
> I think it might be good to always add new tests to the end of the
> list.  That way if there is an email thread referring "test 17" in
> foo_tests.py, we will not affect the numbering and confuse that
> thread.
>
> Of course, in theory, we should always refer to tests by name anyway,
> but sometimes people get careless.  If there's no reason to add a test
> to the middle of the list, the end seems like the best place to me.
>
> Thoughts?
>   

Thanks Karl, Fixed in r26028.

With regards
Kamesh Jayachandran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org