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.
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.
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".
-g
On Wed, Oct 1, 2008 at 12:00 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Oct 1, 2008 at 2:46 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> 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.
>
> Not to sound like a douche, but I think Subversion releases are for
> our users not for us. I think it is OK to add changes that do not
> bring benefits, I am more concerned about causing new problems. My
> specific concerns here are:
>
> 1) The SQLite dependency may lead to unexpected packaging and
> deployment problems. Your point is "great, let's get those worked
> out." Mine is "this would be easier if we had some great benefits to
> go with it and make people think it is worth the pain."
>
> 2) Using SQLite in the manner planned for 1.6 could have performance
> or other regressions. I am not saying it will but this code will not
> exactly have soaked for very long before we branch.
>
> Are there no benefits we can think of for doing this? Fewer files
> (inodes) in the WC? Anything? My concerns could turn out to be
> non-issues ... they probably will be non-issues. It just seems like
> there ought to be some benefits to adding this if we are going to do
> it.
>
> --
> 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 21:12:14 CEST