You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2008/01/24 14:16:13 UTC
My understanding of state of things on sqlite storage
Hi All,
I could observe that we no more record mergeinfo in sqlite. This causes
all 5 issue-2897 specific testcases to fail.
But we have a code that does some insertions to sqlite table but not
exercised thanks to r28134.
As we are not recording anything in sqlite, I expected 'log -g and blame
-g' to fail.
Yes they fail, but they are expected to fail since r28948 and hence our
testsuite passes.
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.
FYI: issue-2897 only needs equivalent of 'mergeinfo_changed', it does
not use 'mergeinfo'.
3)Remove all traces of sqlite relating to mergeinfo storage.
Let me know in case I misunderstand anything.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: My understanding of state of things on sqlite storage
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 24, 2008 7:26 AM, C. Michael Pilato <cm...@collab.net> wrote:
> David Glasser wrote:
> > On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <ka...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: My understanding of state of things on sqlite storage
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <ka...@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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: My understanding of state of things on sqlite storage
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 24, 2008 10:09 AM, David Glasser <gl...@davidglasser.net> wrote:
> On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <ka...@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.
Ahhh! So you have not made that change yet I take it? Or only for
fsfs? I was thinking this was part of the reintegrate branch which is
also why I thought the SQLite usage had all been removed. Maybe you
only did it for fsfs?
--
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
Re: My understanding of state of things on sqlite storage
Posted by Kamesh Jayachandran <ka...@collab.net>.
David Glasser wrote:
> On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <ka...@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.
>
I don't have any design yet.
I am still making an effort to understand your work on
'sqlite-mergeinfo-without-mergeinfo'. Will make a proposal or patch if
it is simple soon.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: My understanding of state of things on sqlite storage
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 24, 2008 6:40 AM, Kamesh Jayachandran <ka...@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.
--dave
--
David Glasser | glasser@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
Re: My understanding of state of things on sqlite storage
Posted by Kamesh Jayachandran <ka...@collab.net>.
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.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: My understanding of state of things on sqlite storage
Posted by "C. Michael Pilato" <cm...@collab.net>.
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.
> 3)Remove all traces of sqlite relating to mergeinfo storage.
Yup.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand