[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tree-conflicts: patch for improved cmdline tests

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 19 Aug 2008 10:47:08 -0400

On Tue, Aug 19, 2008 at 10:29 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Greg Stein" <gstein_at_gmail.com> writes:
>> Yeah. XFail seems the right way to go.
>>
>> I'd prefer to see these tests added to trunk rather than the branch.
>> More testing on the trunk never seems bad :-) And it isn't like
>> they'll interfere with any other trunk development or break something
>> in trunk. But they *can* help with other dev that might be happening
>> there.
>>
>> Thoughts?
>>
>> (my one possible "con": working on both trunk and a branch, but that
>> might be an okay thing)
>
> I'd always thought our principle was that every change should go to
> trunk unless there's a specific reason why it must go on a branch.
>
> For example, that means that if you're working on a feature branch and
> you encounter some buglet that interferes with the feature work, you
> still fix the buglet on trunk and port the change over to the branch
> (because the buglet is not "about" the branch work, it just interferes
> with the branch work).
>
> So unless there's a reason why these tests would cause trouble on trunk,
> let's put 'em on trunk, the natural home of all changes :-).

It does not make sense to me that if you are developing a new feature
on a branch, you would write the tests for this feature on trunk.
Isn't that kind of burdensome and unnatural for the developer?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-19 16:47:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.