On Wed, Oct 1, 2008 at 12:26 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
The benefit is that we are ABLE to take a step in the direction we
need to go. The dependencies across WC are *so* intertwined (the
reason for its brittleness, inability to properly maintain it,
difficulty to extend, etc) that we MUST find a way to untangle pieces.
As far as I can tell the only "risk" is that we pick up one more
dependency. And that is on something which is pretty much everywhere
and is packaged by everybody.
>> 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?
Internal code improvements.
If I have a spurt of coding craziness, then maybe I can combine them
rather than scatter them around per-directory.
I also have a place to put *other* data into a sqlite database. I've
also considered moving properties into there as a "divisible" work
item.
Depends on timing, but we at least get the code improvements.
>> 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.
It's not transition code. The code in WC "above" the wc_db API will
have no idea where the data is located. We make an internal change,
and now all the data is located in one place and is shared across all
WCs. The consumer of the API has no idea.
This is the point: by making a hard separation across API boundaries,
then we get flexibility and maneuverability within the WC
implementation.
And it is not different from the future. It is one step. The table
used for the refcounts is going to be the same table used in the
future. No changes. That's why I've designed the *full* schema for a
WC rewrite. And now I've picked out one element of it.
-g
---------------------------------------------------------------------
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:46:06 CEST