Re: svn commit: r33126 - trunk/subversion/libsvn_wc

On Wed, Sep 17, 2008 at 7:05 AM, John Szakmeister <john_at_szakmeister.net> wrote:
>...
>> +svn_wc__db_open_many(apr_hash_t **dbs,
>> + const apr_array_header_t *paths,
>> + svn_config_t *config,
>> + apr_pool_t *result_pool,
>> + apr_pool_t *scratch_pool);
>
> Just trying to understand the motivation for such a function... is
> this to support externals? Or is there something else that I'm
> missing?

$ svn up path/to/wc1 path/to/wc2 path/to/wc3

That could be three databases (if they are wcroot-based), or it could
be one if home-based. If the latter, then we want to open and use just
one database for all operations. If we had used the plain open()
interface, then we'd end up with three separate handles onto that
database.

Another case:

$ svn up path/to/wc/foo path/to/wc/bar

In this, we could have one database at wc/.svn/ and maybe somebody
moved bar in there for a combined wc, so another exists at
wc/bar/.svn/.

But as I was writing this, I realized that a combined working copy
might not even be stated on the command line. That we would find it
during a traversal, so:

$ svn up path/to/wc

could end up referring to many administrative databases. Ideally, we
could prompt the user and say "can I combine these datastores to
optimize the operation of this working copy?"

Hmm. May be that one handle needs to be able to manage multiple
datastores... If that's the case, then the API that I just added would
take an array, but return just one handle (rather than a hash)

Cheers,
-g

---------------------------------------------------------------------
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-17 16:56:46 CEST