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

Re: My understanding of state of things on sqlite storage

From: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 24 Jan 2008 07:45:30 -0800

On Jan 24, 2008 7:26 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> David Glasser wrote:
> > On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
> >> C. Michael Pilato wrote:
> >>> Kamesh Jayachandran wrote:
> >>>> With this I tend to think we need to do 3 things,
> >>>>
> >>>> 1)In trunk Make 'get_mergeinfo_for_tree' API to be sqlite independent.
> >>>>
> >>>> 2)In issue-2897 branch make 'get_commit_and_merge_ranges' extract
> >>>> data from fs rather than from sqlite.
> >>> 2b) Implement all the other mergeinfo queries for BDB, too.
> >> Thanks for clarifying that, I am working on implementing 2) right now.
> >
> > That's good to hear. What is your design for doing this efficiently?
> >
> > The design I've been imagining involves adding a field to noderevs
> > "predecessor-where-mergeinfo-changed" or something.
>
> /me sighs as the beautiful design of the filesystem DAG crumbles into a
> giant mess, basically all because of one feature's supposed need for
> property inheritance.

Hey, it just makes it into a DAG with more types of edges :-)

This does make it clear that all the people who've been saying for
years "property inheritance is easy in the Subversion model" are
wrong. (Honestly I also think now that nestable mergeinfo was the
wrong choice since it leads to so much unpredictable semantics. Oh
well.)

--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
Received on 2008-01-24 16:46:11 CET

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.