[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge tracking use cases

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-01 00:46:48 CET

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.)


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 00:46:59 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.