Re-reading your original email...
The new API allows for compressing the text base files. Pretty much
transparently. So yah... there could be improvements.
But I still maintain that it doesn't matter. 1.6 comes with a lot of
improvements, and it needs sqlite.
Inside, we start moving towards a maintainable WC library, which
everybody has wanted for something like three years now. So my opinion
is pretty much "done deal" unless there is a better way to make some
steps towards a cleaner WC library.
-g
On Wed, Oct 1, 2008 at 7:34 AM, Mark Phippard <markphip_at_gmail.com> 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.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
---------------------------------------------------------------------
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 23:34:47 CEST