[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: current plan for WC

From: Listman <listman_at_burble.net>
Date: Wed, 1 Oct 2008 09:00:46 -0700

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

This is an archived mail posted to the Subversion Dev mailing list.