David Glasser wrote:
> On Nov 30, 2007 3:32 PM, Karl Fogel <kfogel@red-bean.com> wrote:
>> I do want to point out, though, that David Glasser's work on
>> eliminating sqlite usage is still valuable *even* if we ship with an
>> sqlite dependency in 1.5 (for issue #2897).
>>
>> First, minimizing our use of sqlite is still good, in terms of
>> reducing complexity. And second, no rule says we can't lose a
>> dependency in a future release. If we solve #2897 using sqlite now,
>> and later learn how to solve it without sqlite, that's okay -- we're
>> allowed to drop sqlite as a dependency later. I'm not saying that's
>> the ideal route, of course, but it's a route.
>
> Just to clarify: I'm not trying to get rid of sqlite because I don't
> want a dependency. I don't want to get rid of it just because "we
> can". I want to get rid of it because I can't imagine that we will
> come up with a way to fix the serious problems involved with
> simulating svn lazy copy operations in an acceptable way in the next
> few weeks. Of course, I could be overreacting; I only discovered
> these issues a few days ago, and nobody has really tried to figure out
> how to fix them. I am just skeptical that it would be easy, and I
> don't see how Kamesh's #2897 is going to be acceptable if we don't fix
> that underlying problem.
>
> (The point is that the entire paradigm for how libsvn_fs_{fs,base}
> communicates with the sqlite implementation would need to be changed.
> Currently the only way the sqlite gets updated is by the FS library
> saying "we're about to finish our commit, here are some mergeinfo
> changes based on collecting data from svn_fs_change_node_prop". But
> we also need to collect data in svn_fs_copy and svn_fs_delete_node,
> and that data is not simple, and then it has to be given to the sqlite
> layer, and then the sqlite layer needs to simulate all of the svn
> operations, and what happens if we have nested copies and deletes and
> it just becomes an enormous mess. And it's a mess we're capable of
> solving, but I'd expect the timescale for solving that mess to be a
> month or two of work (including design), and there are *so many* other
> things on merge tracking alone that need to be worked on. as well.)
I'm using the Subversion repository just as a versioned filesystem and don't
care about having svn_fs_copy() and svn_fs_delete_node() managing merge info, in
fact, for performance, I would rather not see it do that work at all in my
application.
If we go down this route, can we have new versions of these methods that do no
merge tracking, say svn_fs_copy_no_merginfo() or something clumsy like that and
the new svn_fs_copy() calls svn_fs_copy_no_merginfo() then does the mering work?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 02:27:26 2007