On Nov 30, 2007 6:46 PM, David Glasser <glasser@davidglasser.net> 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.)
FWIW, I like what David has done and it all makes a lot of sense in
solving the problems. I see a lot of messages where everyone is
assuming that 2897 requires SQLite. We all assumed the same for MT
and David has proven we do not. I think we need to get a clear answer
from Kamesh about what the exact info is that he needs so that we can
explore whether the repository can provide that information.
It seems like the only time we would need SQLite is if we needed to do
a complicated query of a tree. I did not get the impression that
Kamesh's change needed that. I thought what it needed was to store
some extra info that stated specifically what revisions were merged.
It seems like we could accomplish that (possibly) using just the
repository.
If so, then we could eliminate SQLite, which would solve the problems
David described (and in which must be solved) and we could implement
David's repository change to support log -g.
Assuming Kamesh has some kind of decent solution in progress, and we
can replace the part that needs to access SQLite, we could
realistically have these problems dealt with in a decent timeframe.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 01:23:05 2007