This will continue to be per-directory like now. I don't want to sign
up for collecting the pristine files into one directory just yet.
That's step two :-)
And this is just managing the pristine files, so there is no metadata
about the WORKING/ACTUAL trees, meaning that "svn edit" won't be
possible.
Cheers,
-g
On Wed, Oct 1, 2008 at 9:00 AM, Listman <listman_at_burble.net> wrote:
>
> On Oct 1, 2008, at 7:34 AM- Oct 1, 2008, Mark Phippard wrote:
>
>> On Tue, Sep 30, 2008 at 11:43 PM, Greg Stein <gstein_at_gmail.com> wrote:
>>
>>> I've chatted a bit about this on IRC, but wanted to bring it on-list
>>> for discussion.
>>>
>>> The WC-NG is a big effort that can't be "just dropped in whole", so
>>> I've been considering ways to bring it in piecemeal. My current plan
>>> for a "next step" is the following:
>>>
>>> * text base management will be handled under the wc_db.h APIs
>>>
>>> * this will require sqlite to track refcounts for the bases
>>>
>>> * bases will be kept in .svn/pristine/... on a per-dir basis like
>>> today. no aggregation will occur.
>>>
>>> * access batons will learn about svn_wc__db_t as a step towards
>>> migration solely to db_t rather than access batons
>>>
>>> * another wc format upgrade will occur to migrate the bases into their
>>> new home
>>>
>>>
>>> The sqlite dependency may also be used by the fs-rep-sharing if that
>>> makes it in for 1.6. But this will also give us some time to flesh out
>>> the addition of a new dependency in our build, our docs, and our
>>> downstream bundlers.
>>>
>>> The impact "should" be rather light, as it should simply be a
>>> reorganization of the bases under the .svn directory, and how we
>>> access those bases. Given that we key from checksum instead of file
>>> name, this shold also simplify the recent "revert base" work that Karl
>>> has done (no need for two bases under the same name; they'll simply be
>>> keyed by their differing checksums).
>>>
>>> I have committed some new APIs in libsvn_wc/svn_db.h for managing the
>>> pristine files, and have done a first pass at implementing them (minus
>>> reliance on a sqlite db). Any comments/review is more than welcome.
>>>
>>> I'm also interested in hearing feedback on this plan as a first step.
>>> I think this is about as far as we can get for 1.6, and it should be a
>>> light impact for this stage of the release process. The 1.7 work will
>>> be more substative, but will occur throughout the 1.7 dev process,
>>> rather than near the end. Comments, please.
>>
>> I am not against this idea, but it seems like we ought to be
>> delivering something that provides some kind of improvement to the
>> user. We are basically saying let's do it now so we can shake out
>> bugs related to packaging SQLite. But why push that on to packagers
>> and users without providing some corresponding benefits? Is this
>> going to improve performance or space at all? Is it going to make 1.7
>> development that much easier to do this now? It does not sound like
>> it.
>>
>> It seems like we are injecting risk into the 1.6 release without
>> having any "payoff" to make the risk worth taking. So I guess what I
>> am saying is if we really want to do this, then I'd like to hear some
>> benefits we are going to get for taking this risk.
>>
>
> will this proposed change centralize the .svn metadata into one location or
> will it remain scattered across the working copy hierarchy
>
> +1 to some tangible peformance benefit for migrating to 1.6 - how about the
> (optional) svn edit command that reduces the maddeningly slow disk "churn"
> required by svn status??
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 20:40:29 CEST