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

Re: [PATCH] svn status to report tree conflict victims

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 25 Sep 2008 11:05:56 +0100

On Mon, 2008-09-22 at 23:14 +0100, Julian Foad wrote:
> On Fri, 2008-09-19 at 18:33 +0200, Stefan Sperling wrote:
> > On Fri, Sep 19, 2008 at 03:34:12PM +0100, Julian Foad wrote:
> > > I don't want to bike-shed about this. I think the best thing to do here
> > > is to go for a separate column, so that we're not hiding any
> > > information. It will be easier to judge whether the extra information is
> > > really useful if we can see it than if we hid it to start with.
> >
> > +1
> >
> > Let's try an extra column first.
> > We can still change it if it turns out that we don't like it.
> Of course that means we have to modify a whole bunch of existing tests
> just to cope with having an extra column, before we start using it.
> I'm doing that right now, in a separate commit. It will add a blank
> column after the first six columns.

The blank column was added in r33247, and the "T" status was added into
that column in r33288.

I made the test suite ignore this status code when comparing an actual
and an expected status, if the expected status StateItem has the default
value of None for the attribute "treeconflict". This status is compared
only if the test explicitly specifies the expected value as
StateItem(..., treeconflict='T') or StateItem(..., treeconflict=' ').

This means we don't have to modify the many existing tests that raise a
tree conflict until we are ready to do so. And that's particularly handy
because the status "T" isn't yet printed in all the cases it should be,
so it will be nice to get that right first and then adjust all the tests
to test it once and for all, rather than adjusting them to a part-way
state now and then adjusting them again later.

It also seems right as a general theory that a test should not be forced
to test things it is not interested in. A test should test one thing,
and other tests should test the other things. Hmm, maybe that's the
distinction between a "unit test" and a "regression test": the former
should test one thing, but the latter should check that a whole scenario
runs exactly as it did before. We don't seem to make any distinction in
our test suite.

- Julian

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-25 12:06:19 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.