[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 1 Oct 2008 15:26:17 -0400

On Wed, Oct 1, 2008 at 3:11 PM, Greg Stein <gstein_at_gmail.com> wrote:
> At *some* point, the SQLite dependency will be added. Thus, our
> downstream packagers have to deal with it at some point. That is now,
> or that is later, but it will happen.
> Benefit is orthogonal. 1.6 brings value. Done. People will upgrade.
> Strictly speaking, there is no reason to tie cost/benefit to the
> *same* feature. 1.6 comes with some benefits, and 1.6 may be a teensy
> bit harder to package. These are taken as lumps. Not broken down.

The best I can respond is that I do understand what you are saying
here. It still sounds like risk to me and I just want to know why it
is worth the risk.

> I'm proposing to get this rewrite started. The WC is NOT a library
> that we can replace in one chunk. It *has* to be incremental. I've
> identified an increment that we can absorb. It is pretty much an even
> trade at the disk level: files are named a bit differently, but there
> are still the same number. The WC *code* on the other hand will begin
> to be partitioned across the wc_db API lines. The higher levels will
> start to manage a context, will start to manage files with it, will
> pass around that handle, etc. We need to see how that process is going
> to pan out. We need to see if "db handle is needed; do we need a
> wc_ctx added into our APIs yet?" and questions like that.

Can you give some more details about how you would use SQLite in 1.6?
Is there a database in every .svn folder? I have to assume yes. What
would it contain? You mentioned refcounts. Given that each folder
still has a .svn what exactly is that providing?

> Basically, we HAVE to find a way to start the process of a complete
> rewrite of WC. If you have another suggestion on a better place to
> start, then I'm all ears. But I'm going to get very cranky if you say
> "delay your work".

I had the impression that any usage of this in 1.6 will be so
different than what you ultimately plan for the rewrite that the
benefit would be minimal to the rewrite. If you are saying this is
going to make the rewrite easier ... then I guess that is good. What
do we do if/when 1.6 bugs show up and trunk has really moved on to a
different place? I know we have that issue no matter what, it is the
nature of a rewrite. But there is still a difference from supporting
a piece of transition code and supporting the code that has been
around forever.

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 21:26:36 CEST

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