[RFC] readonly branch and repository tests

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> We have several scenarios where we want to make sure bzr can do readonly
> operations on branches and repositories, but not read-write ones.
> 
> Specifically:
>  - Bundle 5 is likely to be a branch-as-a-bundle (or at least I think
> its well worth trying for) - this is a readonly repository and branch
> implementation, so mutating tests are pointless.
>  - bzr-hg, bzr-git, bzr-cvs if it is created - none of these should be
> required to write to the backend losslessly, and being able to just
> 'pull' with confidence would be a great win. And we cannot represent in
> these other systems all the things that we do - forcing a real-time
> export (which is what write support to a foreign format is) - as the
> price to be able to test these things is basically ugly.
> 
> So I'm thinking about how to structure our per-implementation tests to
> cater for this.
> 
> I'm thinking that there are three basic steps:
>  - tag readonly implementations somehow - starting with Branch4
>  - split out the tests of mutating interfaces somehow.
>   * Possibly decorate them
>   * possibly split the directories to keep our simple approach
>   * possibly a different list in the per-FOO/__init__.py.
>  - change the readonly tests to call a method on self after setting up
> the scenario, which will transform the branch/repository into the real
> format needed, and then the test can proceed. I see this working much
> like the InterTree adaption function works - which has been quite
> successful I thought in letting us test things that interact with
> RevisionTree.
> 
> Thoughts?
> -Rob

I really like the idea of splitting up things into what a "readonly"
implementation test can handle versus what a "read-write" one can.
(writeonly? :)

I was actually thinking to have them be an extra base class. So you
would have:


class ReadOnlyRepository(object):
...

class ReadWriteRepository(ReadOnlyRepository):

or maybe

class Repository(ReadOnlyRepository):


and then plugins that are implementing read support could inherit from
the right base class, and have it be clear what they support. (And then
we would have readonly_repository_implementations tests, etc).

We still need a way to generate the source trees.

For myself, I think a "Builder" api *could* work. However, I've also use
"canned" repositories for some stuff when testing. So I have a test
which needs "a merge and *this* changed". And so I manually create a
branch of whatever source that does that, pack it up into a tarball, and
include it.

It *does* make it harder to write a new test which exercises a different
api, etc. But it means I don't have to worry about making a Builder
which does X.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGe93eJdeBCYSNAAMRArePAJ9ebcOuvtb7nsN17Cw9miJFXMJRKgCgwqtF
X4MHdeOdElk1/xpz5A+y/BU=
=bvLA
-----END PGP SIGNATURE-----