Merge lp:~bzr/bzr-svn/stacks into lp:bzr-svn/1.1

[Vincent Ladeuil]

This should be enough to make bzr-svn compatible with the config stacks.

As discussed, I didn't try to make it compatible with previous versions of
bzr, as such I'm proposing this for discussion (and used
lp:~bzr/bzr-svn/stacks so we can both push there).

One important thing to keep in mind too: using the previous design is still
supported so the options can still be accessed via both APIs. What matters
is whether bzr-svn is using specific options (use whatever fit the need) or
options also used by bzr (in which case as options are migrated they will
start relying on get_config_stack() being implemented as shown here).

Overall, except from the minor nits I bothered you with on IRC (thanks for
the explantions ;) this was pretty straight forward:

- a specific store,
- a section matcher,
- a stack

For the later, I almost had an heart attack when you mentioned that the
modifications are always done in locations.conf... until I realized the
stack can perfectly support that: a mutable store and a mutable section name
is all that is required, nobody ever said it should always be branch.conf
for a branch ;)

[Jelmer Vernooij (jelmer)]

Thanks!

[Jelmer Vernooij (jelmer)]

This indeed looks a lot saner than what bzr-svn was doing previously, and is hopefully also less prone to breakage.

23 +# Inject our config stuff to be tested against the bzr test suite
24 +_mod_bzr_config.test_store_builder_registry.register_lazy(
25 + 'subversion', "bzrlib.plugins.svn.tests", "build_SubversionStore_for_test")
26 +_mod_bzr_config.test_stack_builder_registry.register_lazy(
27 + 'subversion', "bzrlib.plugins.svn.tests", "build_SvnBranchStack_for_test")

This seems a bit unnecessary to me. I'd much rather just define a SvnBranchStackTests class in bzrlib.plugins.svn.tests.test_config that derives from some base StackTests test class in bzrlib.tests.test_config.

[lp:~bzr/bzr-svn/stacks]

4044. By Vincent Ladeuil on 2011-10-05

Subclass matcher tests instead of duplicating them.

4045. By Vincent Ladeuil on 2011-10-05

Subclass store tests instead of using the registry.

4046. By Vincent Ladeuil on 2011-10-05

Remove the duplication. It doesn't exist in the bzrlib tests, it shouldn't exist here either.

4047. By Vincent Ladeuil on 2011-10-05

Subclass stack tests instead of using the registry.

4048. By Vincent Ladeuil on 2011-10-05

Remove cruft.

[Vincent Ladeuil (vila)]

> This indeed looks a lot saner than what bzr-svn was doing previously, and is
> hopefully also less prone to breakage.
>
> 23 +# Inject our config stuff to be tested against the bzr test suite
> 24 +_mod_bzr_config.test_store_builder_registry.register_lazy(
> 25 + 'subversion', "bzrlib.plugins.svn.tests",
> "build_SubversionStore_for_test")
> 26 +_mod_bzr_config.test_stack_builder_registry.register_lazy(
> 27 + 'subversion', "bzrlib.plugins.svn.tests",
> "build_SvnBranchStack_for_test")
>
> This seems a bit unnecessary to me. I'd much rather just define a
> SvnBranchStackTests class in bzrlib.plugins.svn.tests.test_config that derives
> from some base StackTests test class in bzrlib.tests.test_config.

I tried that. This allowed me to fix the bzrlib tests a bit (I'll submit
that later, some tweaks and 2 bogus tests there).

So the try was worth it but I'm not fully convinced by the result.

Unfortunately the intermediate diff is not crystal clear as I removed some
duplication from my first submission.

In summary, the 2 registrations are replaced by 10 test classes each with
their own setUp() to replace the parametrization. As mentioned on IRC, this
open the door to divergence if more classes are added.

This means the tests are now part of -s bp.svn but all the debug still
happen in the base class, not super sexy to use.

[Robert Collins (lifeless)]

FWIW parameterisation is a lot nicer than subclassing most of the time.

[Jelmer Vernooij (jelmer)]

> > This indeed looks a lot saner than what bzr-svn was doing previously, and is
> > hopefully also less prone to breakage.
> >
> > 23 +# Inject our config stuff to be tested against the bzr test suite
> > 24 +_mod_bzr_config.test_store_builder_registry.register_lazy(
> > 25 + 'subversion', "bzrlib.plugins.svn.tests",
> > "build_SubversionStore_for_test")
> > 26 +_mod_bzr_config.test_stack_builder_registry.register_lazy(
> > 27 + 'subversion', "bzrlib.plugins.svn.tests",
> > "build_SvnBranchStack_for_test")
> >
> > This seems a bit unnecessary to me. I'd much rather just define a
> > SvnBranchStackTests class in bzrlib.plugins.svn.tests.test_config that
> derives
> > from some base StackTests test class in bzrlib.tests.test_config.
>
> I tried that. This allowed me to fix the bzrlib tests a bit (I'll submit
> that later, some tweaks and 2 bogus tests there).
>
> So the try was worth it but I'm not fully convinced by the result.
>
> Unfortunately the intermediate diff is not crystal clear as I removed some
> duplication from my first submission.
>
> In summary, the 2 registrations are replaced by 10 test classes each with
> their own setUp() to replace the parametrization. As mentioned on IRC, this
> open the door to divergence if more classes are added.
Yeah, I agree it's also far from ideal, but I like it better than having to register test helpers in a plugins' __init__.

> This means the tests are now part of -s bp.svn but all the debug still
> happen in the base class, not super sexy to use.
I think to do this right, we need to fix bzrlib.tests.test_config. Perhaps it can provide some sort of multiply method? E.g.

multiply_store_tests(build_store_fn)

This method could then be called inside bzrlib.plugins.svn.tests.test_config.load_tests. It would remove the need to do test helper registration in bp.svn.__init___.

[Vincent Ladeuil (vila)]

> FWIW parameterisation is a lot nicer than subclassing most of the time.

I think so too, thanks for chiming in ;)

[Vincent Ladeuil (vila)]

    >> In summary, the 2 registrations are replaced by 10 test classes each with
    >> their own setUp() to replace the parametrization. As mentioned on IRC, this
    >> open the door to divergence if more classes are added.

    > Yeah, I agree it's also far from ideal, but I like it better than
    > having to register test helpers in a plugins' __init__.

Reminder: the registration have to be done there before either of
bp.svn.tests.test_config or bt.test_config is loaded. No additional file
is loaded by this lazy registration though, so it shouldn't have any
impact on startup times (which is the point of lazy loading).

What exactly do you dislike with registration here ? I'm not trying to
make you take the "blue pill", registration is not meant to be
mandatory. In fact, it defines a very narrow API that should be easy to
implement. I'm not trying to *reduce* the flexibility for plugin authors
(quite the contrary), I'm just trying to make it easy to reuse the
tests.

I'm Ok with investigating alternate ways to get there though.

    >> This means the tests are now part of -s bp.svn but all the debug
    >> still happen in the base class, not super sexy to use.

    > I think to do this right, we need to fix
    > bzrlib.tests.test_config. Perhaps it can provide some sort of
    > multiply method? E.g.

That's what parametrization is about. I don't understand the kind of fix
you're talking about here ?

    > multiply_store_tests(build_store_fn)

more like:

  multiply_store_tests(build_store)
  multiply_matcher_tests(build_store, build_matcher)
  multiply_stack_tests(build_stack, build_store)

which still scales worse than parametrization, while still requiring
implementing the same helpers.

It seems to reduce the flexibility for all parties involved, I'm fine
with plugins not reusing the bzrlib tests but it seems we're
bike-shedding about how they can reuse them.

There are already 2 ways to reuse these tests:

- lazy registration, the simplest, required to be used in __init__ to be
  taken into account in all cases (-s and all that jazz) and be seen as
  additional parametrization of bt.test_config. No performance impact
  should occur here even if the tests are not run.

- subclassing which allow specific additional tests to be run or base
  tests to be skipped or whatever the plugin want to test.

The former guarantees that the plugin conforms to the required API. The
second allows the plugin to diverge from this API or extend it if
needed. Both can or should be used by the plugins depending on what they
implement.

subclassing also requires a more intimate knowledge of what the base
tests are about.

    > This method could then be called inside
    > bzrlib.plugins.svn.tests.test_config.load_tests.

    > It would remove the need to do test helper registration in
    > bp.svn.__init___.

This introduces an additional constraint on bt.test_config. What are the
benefits there ?

ISTM we are walking on the path that led to poolie's introduction of:

  load_tests = scenarios.load_tests_apply_scenarios

Using a registry targeted at tests is the same logic IMHO: the test
class defines an API (the parameters) and we need a way to add som...

[Jelmer Vernooij (jelmer)]

> FWIW parameterisation is a lot nicer than subclassing most of the time.
Sure, I don't disagree with that. I think the parametrization isn't done right here.

[Vincent Ladeuil (vila)]

> Sure, I don't disagree with that. I think the parametrization isn't done
  right here.

Not telling me in what way it's not done right, doesn't help me much ;)

One issue I can think of is about how these tests are named, because it has
an impact on how -s will work with them:

- if they are named as bt.test_config, -s bt.test_config includes them
  (while respecting BZR_PLUGIN_PATH and friends)

- if they are named as bp.svn, -s bp.svn includes them but -s bt.test_config
  doesn't anymore

In fact, they cannot be part of -s bt.test_config without some help from
svn/__init__.py otherwise even the load_tests() there is ignored so no
tests/ file has a way to add them.

There may be a trick to duplicate the tests under both hierarchies but same
care should be taken if both are selected.

The parametrization is about deciding which tests should be run with which
scenario.

The store scenario is:

  ('subversion', {'get_store': store_builder, 'store_id': 'subversion'})

The stack scenario is:

  ('subversion', {'get_store': store_builder, 'get_stack': stack_builder})

The matcher scenario (not sure we really want scenarios for matchers, but if
we want):

 ('subversion', {'get_store': store_builder,
                 'store_id': 'subversion',
                 'matcher': matcher_class})

From that which test classes should be used is decided either in bzr or in
bzr-svn.

Deciding from bzr allows to define the required interface.

Deciding from bzr-svn allows to define which interface you agree to
implement.

Asking for more control about the test classes requires knowledege about
them.

I don't know where you stand on that.

You certainly have a great deal of experience with plugins needing to respect
an interface, parametrized or not.

My two proposals for that seems to be at the two extremes, do you have a
preferred sweet spot between them ?

I've started defining:

def multiply_store_tests(tests, result, store_builder):
    scenarios = [('subversion', {'get_store': store_builder,
                                 'store_id': 'subversion'})]
    return tests.multiply_tests(tests, scenarios, tests)

def multiply_matcher_tests(tests, store_builder, matcher_class):
    scenarios = [('subversion', {'get_store': store_builder,
                                 'store_id': 'subversion',
                                 'matcher': matcher_class})]
    return tests.multiply_tests(tests, scenarios, tests)

def multiply_stack_tests(stack_builder, store_builder):
    scenarios = [('subversion', {'get_store': store_builder,
                                 'get_stack': stack_builder})]
    return tests.multiply_tests(tests, scenarios, tests)

in bzr-svn but that still need to know:

- which test classes should be used,

- and derived from that, how the tests should be named.

There are infinite ways to proceed and I don't think iterating them all is
the best use of our time ;) Can we agree on something and make it evolve as
we encounter the issues and better understand the problem ?

[Vincent Ladeuil (vila)]

pingeling

[Jelmer Vernooij (jelmer)]

Sorry for taking so long to get back to you on this. I've given it some more thought.. perhaps we can unblock this.

> > Sure, I don't disagree with that. I think the parametrization isn't done
> right here.
> Not telling me in what way it's not done right, doesn't help me much ;)

Test stuff should be as much as possible isolated to the test side of the code - and not be executed as part of normal operations. I still think this is not a good use of registries, but having this sort of registration in the load_tests code of bzr-svn would be a lot nicer than where it is now.

> One issue I can think of is about how these tests are named, because it has
> an impact on how -s will work with them:
>
> - if they are named as bt.test_config, -s bt.test_config includes them
> (while respecting BZR_PLUGIN_PATH and friends)
>
> - if they are named as bp.svn, -s bp.svn includes them but -s bt.test_config
> doesn't anymore
>
> In fact, they cannot be part of -s bt.test_config without some help from
> svn/__init__.py otherwise even the load_tests() there is ignored so no
> tests/ file has a way to add them.

This is already the case for a lot of other things, so I don't think it would be a problem if -s bt.test_config didn't execute them. For example, compare "bzr selftest -s bt.per_interbranch" and "bzr selftest bzrlib.tests.per_interbranch". The latter also includes all plugins, the former does not.

"make check" in bzr-svn simply runs "bzr selftest Svn svn Subversion" and that works fine and includes all relevant tests.

> The parametrization is about deciding which tests should be run with which
> scenario.

> [...]

> Asking for more control about the test classes requires knowledege about
> them.
>
> I don't know where you stand on that.
>
> You certainly have a great deal of experience with plugins needing to respect
> an interface, parametrized or not.
>
> My two proposals for that seems to be at the two extremes, do you have a
> preferred sweet spot between them ?
Having to know the test classes in bzr-svn is fine with me; there is always going to be some churn in the interfaces bzr-svn is involved in, and that's easy enough to keep up with.

> I've started defining:
>
> def multiply_store_tests(tests, result, store_builder):
> scenarios = [('subversion', {'get_store': store_builder,
> 'store_id': 'subversion'})]
> return tests.multiply_tests(tests, scenarios, tests)
>
>
> def multiply_matcher_tests(tests, store_builder, matcher_class):
> scenarios = [('subversion', {'get_store': store_builder,
> 'store_id': 'subversion',
> 'matcher': matcher_class})]
> return tests.multiply_tests(tests, scenarios, tests)
>
>
> def multiply_stack_tests(stack_builder, store_builder):
> scenarios = [('subversion', {'get_store': store_builder,
> 'get_stack': stack_builder})]
> return tests.multiply_tests(tests, scenarios, tests)
>
> in bzr-svn but that still need to know:
Wouldn't it be possible to do it the other way around? Making bzrlib.tests.test_config export a bunch of multiply methods ...

[Vincent Ladeuil (vila)]

<snip/>

    > Test stuff should be as much as possible isolated to the test side
    > of the code - and not be executed as part of normal operations.

Right. I did my best to reduce the test related code invasion to a
minimum but I agree this still has a bad smell. I thought this minimum
was small enough to be ignored but I understand you can disagree ;)

    > I still think this is not a good use of registries,

That's the part I don't get, so, let's forget this proposal for a
second. Can you point where their usage causes problems in
bzrlib/test_config ?

I ended up introducing them because it made it easier for me to add new
stores, stacks and so on, and get them tested instantly for the existing
features so I could focus on the newly introduced ones only.

    > but having this sort of registration in the load_tests code of
    > bzr-svn would be a lot nicer than where it is now.

Then, with the caveat I mentioned below (and you seem to be ok with),
that seems do be the best way to go (see my comments below on
alternatives).

That will just mean moving the registrations in load_tests in which case
*calling* load_tests is the only thing that needs to happen to have the
svn-specific tests run.

    >> One issue I can think of is about how these tests are named, because it has
    >> an impact on how -s will work with them:
    >>
    >> - if they are named as bt.test_config, -s bt.test_config includes them
    >> (while respecting BZR_PLUGIN_PATH and friends)
    >>
    >> - if they are named as bp.svn, -s bp.svn includes them but -s bt.test_config
    >> doesn't anymore
    >>
    >> In fact, they cannot be part of -s bt.test_config without some help from
    >> svn/__init__.py otherwise even the load_tests() there is ignored so no
    >> tests/ file has a way to add them.

    > This is already the case for a lot of other things, so I don't
    > think it would be a problem if -s bt.test_config didn't execute
    > them.

Well, for the bzrlib/config.py maintainer, having the plugin tests
executed while fixing bugs or adding features is way simpler than to
have to execute all the plugin tests (even restricted to the config
related ones).

    > For example, compare "bzr selftest -s bt.per_interbranch" and "bzr
    > selftest bzrlib.tests.per_interbranch". The latter also includes
    > all plugins, the former does not.

Yup, that's what I wanted to address. If the plugin is enabled, so are
the tests.

We still seem to talk past each other. May be it's a difference
between bzrlib/config and plugins points of view ?

Is there some plugin specific issue I fail to understand here ?
Compatibility related may be ?

    > "make check" in bzr-svn simply runs "bzr selftest Svn svn
    > Subversion" and that works fine and includes all relevant tests.

That's your call and I respect that.

    >> The parametrization is about deciding which tests should be run with which
    >> scenario.

    >> [...]

    >> Asking for more control about the test classes requires knowledege about
    >> them.
    >>
    >> I don't know where you stand on that.
    >>
    >> You certainly have a great deal of experience with plugins needing to respect
    >> a...

[Jelmer Vernooij (jelmer)]

> > I still think this is not a good use of registries,
> That's the part I don't get, so, let's forget this proposal for a
> second. Can you point where their usage causes problems in
> bzrlib/test_config ?
Registries are basically lazy dictionaries. One of their key points is that it is possible to retrieve a single item by key without loading any of the rest of the registry. The way they're being used here is more as a way of delayed lists. The key is basically ignored.

The current tests also require a fair amount of setup - and that's currently done with a function that gets passed the TestCase class. This then makes life hard for bzr-svn setup, because bzr-svn has its own setup code. With e.g. a mixin this wouldn't be as problematic.

Code like:

if getattr(test, 'backing_branch', None) is None:

is too magical imho.

> I ended up introducing them because it made it easier for me to add new
> stores, stacks and so on, and get them tested instantly for the existing
> features so I could focus on the newly introduced ones only.
>
> > but having this sort of registration in the load_tests code of
> > bzr-svn would be a lot nicer than where it is now.
>
> Then, with the caveat I mentioned below (and you seem to be ok with),
> that seems do be the best way to go (see my comments below on
> alternatives).
>
> That will just mean moving the registrations in load_tests in which case
> *calling* load_tests is the only thing that needs to happen to have the
> svn-specific tests run.
I'm still not thrilled about that, but I could live with it.

The current branch is also reasonable enough for me, so I'm happy to land that.

> >> One issue I can think of is about how these tests are named, because it
> has
> >> an impact on how -s will work with them:
> >>
> >> - if they are named as bt.test_config, -s bt.test_config includes them
> >> (while respecting BZR_PLUGIN_PATH and friends)
> >>
> >> - if they are named as bp.svn, -s bp.svn includes them but -s
> bt.test_config
> >> doesn't anymore
> >>
> >> In fact, they cannot be part of -s bt.test_config without some help
> from
> >> svn/__init__.py otherwise even the load_tests() there is ignored so no
> >> tests/ file has a way to add them.
>
> > This is already the case for a lot of other things, so I don't
> > think it would be a problem if -s bt.test_config didn't execute
> > them.
>
> Well, for the bzrlib/config.py maintainer, having the plugin tests
> executed while fixing bugs or adding features is way simpler than to
> have to execute all the plugin tests (even restricted to the config
> related ones).
I don't really think the bzrlib/config.py maintainer should worry about that - the main point is that the API stays stable, plugin authors should worry about sticking to that API (and the tests can help with that). Sure, we should discuss design implications of the config.py design, but I don't think you should have to worry about bzr-svn test failures.

> > For example, compare "bzr selftest -s bt.per_interbranch" and "bzr
> > selftest bzrlib.tests.per_interbranch". The latter also includes
> > all plugins, ...

[Jelmer Vernooij (jelmer)]

review: Approve

=== modified file '__init__.py'
--- __init__.py	2011-10-04 22:39:59 +0000
+++ __init__.py	2011-10-05 21:11:25 +0000
@@ -53,7 +53,8 @@
     translation = load_plugin_translations("bzr-svn")
     gettext = translation.gettext
 
-from bzrlib import config
+
+from bzrlib import config as _mod_bzr_config # Or we mask plugins.svn.config
 from bzrlib.branch import (
     network_format_registry as branch_network_format_registry,
     )
@@ -394,10 +395,11 @@
 revspec_registry.register_lazy("svn:", "bzrlib.plugins.svn.revspec",
     "RevisionSpec_svn")
 
-config.credential_store_registry.register_lazy(
+_mod_bzr_config.credential_store_registry.register_lazy(
     "subversion", "bzrlib.plugins.svn.auth", "SubversionCredentialStore",
     help=__doc__, fallback=True)
 
+
 foreign_vcs_registry.register_lazy("svn", "bzrlib.plugins.svn.mapping",
                                    "foreign_vcs_svn")
 

=== modified file 'branch.py'
--- branch.py	2011-09-29 08:47:11 +0000
+++ branch.py	2011-10-05 21:11:25 +0000
@@ -80,6 +80,7 @@
     )
 from bzrlib.plugins.svn.config import (
     BranchConfig,
+    SvnBranchStack,
     )
 from bzrlib.plugins.svn.errors import (
     NotSvnBranchPath,
@@ -453,6 +454,9 @@
     def get_config(self):
         return BranchConfig(self.base, self.repository.uuid)
 
+    def get_config_stack(self):
+        return SvnBranchStack(self)
+
     def get_append_revisions_only(self):
         return self.get_config().get_append_revisions_only()
 

=== modified file 'config.py'
--- config.py	2011-09-23 12:10:59 +0000
+++ config.py	2011-10-05 21:11:25 +0000
@@ -23,11 +23,12 @@
     properties,
     )
 
-import bzrlib.config
 from bzrlib import (
     atomicfile,
+    config as _mod_bzr_config,
     osutils,
     trace,
+    transport,
     )
 from bzrlib.config import (
     ConfigObj,
@@ -44,8 +45,6 @@
     BzrError,
     )
 
-from bzrlib.config import LockableConfig
-
 
 def as_bool(str):
     """Parse a string as a boolean.
@@ -71,8 +70,50 @@
 # was seen at.
 
 
-
-class SubversionUUIDConfig(LockableConfig):
+class SubversionStore(_mod_bzr_config.LockableIniFileStore):
+
+    def __init__(self, possible_transports=None):
+        t = transport.get_transport_from_path(
+            _mod_bzr_config.config_dir(),
+            possible_transports=possible_transports)
+        super(SubversionStore, self).__init__(t, 'subversion.conf')
+
+
+class UUIDMatcher(_mod_bzr_config.SectionMatcher):
+    """UUID-based Subversion section matcher."""
+
+    def __init__(self, store, uuid):
+        super(UUIDMatcher, self).__init__(store)
+        self.uuid = uuid
+
+    def match(self, section):
+        return section.id == self.uuid
+
+
+class SvnBranchStack(_mod_bzr_config._CompatibleStack):
+    """SvnBranch stack providing UUID specific options."""
+
+    def __init__(self, branch):
+        bstore = _mod_bzr_config.BranchStore(branch)
+        lstore = _mod_bzr_config.LocationStore()
+        loc_matcher = _mod_bzr_config.LocationMatcher(lstore, branch.base)
+        svn_store = SubversionStore()
+        uuid_matcher = UUIDMatcher(svn_store,
+                                   getattr(branch.repository, 'uuid', None))
+        gstore = _mod_bzr_config.GlobalStore()
+        super(SvnBranchStack, self).__init__(
+            [self._get_overrides,
+             loc_matcher.get_sections,
+             bstore.get_sections,
+             uuid_matcher.get_sections,
+             gstore.get_sections],
+            # All modifications go to the corresponding section in
+            # locations.conf
+            lstore, branch.base)
+        self.branch = branch
+
+
+class SubversionUUIDConfig(_mod_bzr_config.LockableConfig):
     """UUID-based Subversion configuration."""
 
     def __init__(self, uuid):

=== modified file 'tests/__init__.py'
--- tests/__init__.py	2011-09-06 21:21:36 +0000
+++ tests/__init__.py	2011-10-05 21:11:25 +0000
@@ -16,7 +16,10 @@
 
 """Tests for the bzr-svn plugin."""
 
-from subvertpy import NODE_UNKNOWN
+from subvertpy import (
+    NODE_UNKNOWN,
+    repos,
+    )
 import subvertpy.tests
 
 from bzrlib import osutils
@@ -29,6 +32,7 @@
 from bzrlib.workingtree import WorkingTree
 
 from bzrlib.plugins.svn import (
+    config,
     transport as _mod_svn_transport,
     )
 

=== modified file 'tests/test_config.py'
--- tests/test_config.py	2011-09-18 22:26:33 +0000
+++ tests/test_config.py	2011-10-05 21:11:25 +0000
@@ -16,17 +16,110 @@
 
 """Config tests."""
 
+from bzrlib import bzrdir
 from bzrlib.branch import Branch
 from bzrlib.repository import Repository
+from bzrlib.tests import test_config
 from bzrlib.workingtree import WorkingTree
 from bzrlib.plugins.svn.config import (
     NoSubversionBuildPackageConfig,
     PropertyConfig,
     SubversionBuildPackageConfig,
+    SubversionStore,
+    SvnBranchStack,
+    UUIDMatcher,
     )
 from bzrlib.plugins.svn.mapping3.scheme import TrunkBranchingScheme
 from bzrlib.plugins.svn.tests import SubversionTestCase
 
+
+def build_subversion_store(test):
+    return SubversionStore()
+
+def build_svn_branch_stack(test):
+    """See bt.test_config.build_backing_branch."""
+    if getattr(test, 'backing_branch', None) is None:
+        # First call, let's build the branch on disk
+        repo = test.make_repository('branch', format='subversion')
+        test.backing_branch = bzrdir.BzrDir.open(repo.base
+                                                 ).create_branch(lossy=False)
+    b = Branch.open('branch')
+    return SvnBranchStack(b)
+
+
+class TestReadonlySubversionStore(test_config.TestReadonlyStore):
+
+    def setUp(self):
+        super(TestReadonlySubversionStore, self).setUp()
+        self.get_store = build_subversion_store
+
+
+class TestMutableSubversionStore(test_config.TestMutableStore):
+
+    def setUp(self):
+        super(TestMutableSubversionStore, self).setUp()
+        self.store_id = 'subversion'
+        self.get_store = build_subversion_store
+
+
+class TestUUIDMatcherStoreLoading(test_config.TestSectionMatcher):
+
+    def setUp(self):
+        super(TestUUIDMatcherStoreLoading, self).setUp()
+        self.get_store = build_subversion_store
+        self.matcher = UUIDMatcher
+
+
+class TestUUIDMatching(test_config.TestNameMatcher):
+
+    def setUp(self):
+        super(TestUUIDMatching, self).setUp()
+        self.get_store = build_subversion_store
+        self.matcher = UUIDMatcher
+
+
+class TestConcurrentStoreUpdates(test_config.TestConcurrentStoreUpdates):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestConcurrentStoreUpdates, self).setUp()
+
+
+class TestConcreteStacks(test_config.TestConcreteStacks):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestConcreteStacks, self).setUp()
+
+
+class TestStackGet(test_config.TestStackGet):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestStackGet, self).setUp()
+
+
+class TestStackGetWithConverter(test_config.TestStackGetWithConverter):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestStackGetWithConverter, self).setUp()
+
+
+class TestStackSet(test_config.TestStackSet):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestStackSet, self).setUp()
+
+
+class TestStackRemove(test_config.TestStackRemove):
+
+    def setUp(self):
+        self.get_stack = build_svn_branch_stack
+        super(TestStackRemove, self).setUp()
+
+
 class ReposConfigTests(SubversionTestCase):
 
     def setUp(self):