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

[John Szakmeister <jo...@szakmeister.net>]

On Wed, Sep 17, 2008 at 8:52 AM,  <gs...@tigris.org> wrote:
[snip]
> +/**
> + * In most cases, svn operations will deal with multiple targets. Each
> + * target may have a different administrative database, and others will
> + * be sharing a database. This function will open all relevant databases
> + * for the paths identified in @a paths. The databases will be returned
> + * in @a dbs, as a hash mapping the path to an svn_wc__db_t * value.
> + * Database handles will be shared if two paths imply the same database.
> + *
> + * The @a config will be used to identify how to locate the database
> + * for each target listed in @a paths.
> + *
> + * Results will be alloated in @a result_pool, and temporary allocations
> + * will be made in @a scratch_pool.
> + */
> +svn_error_t *
> +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?

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[John Szakmeister <jo...@szakmeister.net>]

Whups!  Forwarding this to the list.

-John


---------- Forwarded message ----------
From: John Szakmeister <jo...@szakmeister.net>
Date: Wed, Sep 17, 2008 at 8:24 PM
Subject: Re: svn commit: r33126 - trunk/subversion/libsvn_wc
To: Greg Stein <gs...@gmail.com>


On Wed, Sep 17, 2008 at 10:56 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 7:05 AM, John Szakmeister <jo...@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.

I see--thanks or the clarification.  How do you correlate paths to
dbs?  Are we going to reference count the handles, and just return the
same handle for paths that point to the same metadata store?

> 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)

I agree, I think it should just return one handle and manage multiple
datastores behind the scene.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Greg Stein <gs...@gmail.com>]

On Wed, Sep 17, 2008 at 7:05 AM, John Szakmeister <jo...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org