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 18:01:09 CEST