This gets the process started in 1.6. If we do *everything* in 1.7,
then we'll compound the development and rollout costs of that version.
This will give us a baseline moving into the 1.7 development line.
And let me throw a question back at you: why do *you* say any change
to Subversion need to add benefit without development/release risk? If
the change to internals get us on a path for long-term benefit, then
that seems more than appropriate.
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 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.
> Mark Phippard
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:46:43 CEST