Missing svn:externals handling functionality in co/export

Greetings to all subversive^H^Honed elements!

[Maybe this should have gone to dev, but as this is our 1st mail to the SVN
MLs, we'll stick to the advice "if in doubt: users".]

We use the svn:externals feature quite extensively in our software projects,
as it allows for a nice modular concept.
Basically we have a software product mainline, which uses svn:externals to
include

* base libraries
* various functional extensions
* data (lexica for various languages etc.)
* client-specific data/code

We're quite up-to-date with SVN versions, all developers run 1.6.12
(r955767), which is also installed on our repository servers.

What we're really missing is a more fine-grained handling of these externals
when doing an export or checkout. Currently, these commands only accept the
'--ignore-externals' option, which seems like a big ON/OFF switch clubbing
the issue to death. We'd propose the following functional extension:

1) add a possible parameter (list) to the --ignore-externals where one could
actually name the URLs (or even better, user regexp/glob patterns for
matching) that are to be ignored. The rest would be accepted/included in the
export/checkout.

2) add a new option --accept-externals, also with the same possible
parameter list, which would name the externals that are to be accepted for
checkout/export. The rest would be ignored.

Usage of these two options would be mutually exclusive. Of course.

This could be a quite seamless and compatible update path, as the default
behavior for giving these options without parameters would imply the
parameters "all", not changing anything in existing scripts using the
--ignore-externals option.

Currently, we have no way of telling svn export to just export "this this
and this" or "all but not this" that is referenced by svn:externals. This
functional enhancement would spare a lot of scripting and kludging.

Comments? Is this desirable or are we missing some options that already
emulate this behaviour?

--
regards,
 Marcel @ PetaMem R&D