[MERGE] Fix for bug 183831

[Geoff Bache]

> A couple of points here; the test suite has become quite slow recently,
> we want to make it a lot faster. We've recently landed patches to
> support parallel testing (--parallel=fork in bzr.dev, for instance)
> which make a massive speedup. If you don't have parallel hardware, you
> can also use the bzr-ec2test plugin with bzr.dev. 2 instances gets you a
> 90 second test suite once the instances are warmed up. And as a bonus,
> they have no plugins to break things:).

Great. Have to try that out. Have been playing around a fair bit on
ec2 recently anyway.

>
> That said, yes, we *do* expect that the plugins shipped to a users
> machine will be passing all their own tests, and for any interfaces they
> implement passing those interfaces as well. If they don't then there is
> a good chance that the plugin will cause problems.

Well, installing cvsps_import will currently cause 3 test failures (2
of which are its own tests) and that's a fairly "blessed" plugin isn't
it? Installing "scmproj" (which is alpha) will cause 1 failure, but I
thought that was the fault of the test actually, which lists the
hidden commands and asserts that the returned text does not contain
"commit". (scmproj introduces a new command "snapshot-commit"). I
leave it to you to beat up those responsible if you think that's
appropriate :)

> I am interested in helping people developing plugins do so safely and
> quickly, and also in helping people wanting to contribute to the core do
> so easily. We do have some tension between 'officially blessed' and 'J
> random' plugins; I'm not sure of the best route forward. Like Aaron I
> see value in having all the plugins present tested by default.
>

A bit of documentation can't do any harm can it? At least make people
who bother to read your "Guide to testing Bazaar" aware of this issue.

>
> Your fix looks potentially ok to me. I suggest putting it in a branch
> [done] and asking igc to run a usertest run over it vs its branch point
> to see if there are changes, as noone seems to have a good off the cuff
> answer.

Sure. I guess "igc" is Ian Clatworthy in the cc list?

> Definitely though, we need more tests, because testing that add is fixed
> is good, but the contract for the low level function is also being
> changed and we should make sure that that doesn't regress by mistake.
> bzrlib/tests/test_osutils.py has a TestOSUtils class that looks
> reasonably appropriate for adding a few small fixtures to.

Sure. But at this point I think you can decide whether to accept this
fix first (pending further tests), and I can write those tests when
you've decided that and I know I'm not wasting my time.

/Geoff