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 16:35:03 CEST