[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:00:35 -0400

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:00:50 CEST

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