Re: how issue-2897 branch solves reflective merges?

On Jan 11, 2008 11:39 AM, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
> On Jan 11, 2008 8:28 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
> > > Could we redo this to be FSFSy? Or does this require SQLite? -- justin
> > >
> > It uses sqlite.
>
> Thanks, but that wasn't quite the question I was asking. =)
>
> I'm not in favor of having SQLite as a dependency if at all possible,
> so let me rephrase the question:
>
> While the current implementation obviously uses SQLite, are the
> algorithms used dependent upon relational features only present in
> SQL? If not, then can we rewrite the algorithms using a flat-file
> index or something similar?

I believe I know how to support the backend from Kamesh's branch
(which may also help fix log -g) with only in-FS annotations, like on
the reintegrate branch.

> I'm not suggesting that you have to do that work before it gets merged
> to trunk, but I guess a number of us (hi dglasser) would like to
> remove SQLite if we can.
>
> The other question that I meant to ask is:
>
> What is blocking issue-2897 branch from being merged to trunk?

I would like there to be more review by people other than me. Kamesh
has done a lot of good work, but I've certainly found a number of
serious (since-fixed) issues, and I'd be surprised if I caught them
all.

My personal preference would be to merge reintegrate to trunk in the
very near future; then update issue-2897 based on that, then to (on
the 2897 branch) reimplement the FS API without SQLite (I'll do that),
while concurrently folks review Kamesh's libsvn_client changes (not
the backend, which as I said I'll rewrite). Then merge that back to
trunk, then remove the SQLite dependency (which also involves
rewriting the node origin cache on FSFS only, which will be very
easy... just store them as small files in a directory or something),
then BRANCH 1.5.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org