You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2011/09/13 05:02:44 UTC
Status of fs-successor-ids
svn_fs_base__get_node_successors() was implemented over 20 months ago.
Right now svn_fs_history_next() has been implemented for both backends
and passes a simple unit test (fs-test 37, node_history()).
https://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/subversion/include/svn_fs.h
https://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/subversion/tests/libsvn_fs/fs-test.c
For the code we already have we need to
- expand unit test
- update design docs
- review the code, various tweaks
The branch doesn't have code for answering questions such as
- where were a given path's parents copied to?
- when was a given path deleted?
- (questions about merges)
- (questions about a directory's properties having changed,
as opposed to `something under that directory' having changed)
The branch doesn't have yet
- consumers of these new APIs
Re: Status of fs-successor-ids
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 15:02:06 -0400:
> On 09/13/2011 02:42 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
> >> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> >>> Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
> >>
> >> The BDB situation should be about the easiest scenario possible. I mean,
> >> it's a database, for crying out loud. My not-completely-thought-out
> >> approach would be: run a cursor over the whole `nodes' table, reading
> >> node-revision-ids (the keys of that table) and precessor-ids (parsed from
> >> the values of that table), and store the reverse mapping in the `successors'
> >> table.
> >
> > In other words, run over the noderev-to-predecessor mapping and reverse
> > it. No argument about /that/. But do we make 'svnadmin upgrade' do
> > that, or do we introduce a bit that says "Set this bit to '1' after
> > you've built the successors mapping"?
>
> I can't answer this right now, because I think it's best answered in the
> scope of all the other changes to the backend for this release, and in
> comparison with other approaches we're willing to entertain.
>
> For example, if this is the only change we make to the BDB backend, then it
> would seem silly to *not* have 'svnadmin upgrade' do the work. If, however,
> there are other changes that are less intrusive, we might wish to let
> 'svnadmin upgrade' pull off a quicker upgrade while still leaving the
> successor-id feature disabled, and then use some other mechanism to populate
> the mapping and enable the feature.
What about people who want to upgrade their repository from 1.7's format
to 1.9's format (perhaps they used a 1.8 server with --pre-1.8-compatible),
and use any new BDB features we might add in 1.9?
[ In any case, I'll start writing the upgrade code. We can later decide
where in the UI to hook it up to. ]
Re: Status of fs-successor-ids
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/13/2011 02:42 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
>> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
>>> Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
>>
>> The BDB situation should be about the easiest scenario possible. I mean,
>> it's a database, for crying out loud. My not-completely-thought-out
>> approach would be: run a cursor over the whole `nodes' table, reading
>> node-revision-ids (the keys of that table) and precessor-ids (parsed from
>> the values of that table), and store the reverse mapping in the `successors'
>> table.
>
> In other words, run over the noderev-to-predecessor mapping and reverse
> it. No argument about /that/. But do we make 'svnadmin upgrade' do
> that, or do we introduce a bit that says "Set this bit to '1' after
> you've built the successors mapping"?
I can't answer this right now, because I think it's best answered in the
scope of all the other changes to the backend for this release, and in
comparison with other approaches we're willing to entertain.
For example, if this is the only change we make to the BDB backend, then it
would seem silly to *not* have 'svnadmin upgrade' do the work. If, however,
there are other changes that are less intrusive, we might wish to let
'svnadmin upgrade' pull off a quicker upgrade while still leaving the
successor-id feature disabled, and then use some other mechanism to populate
the mapping and enable the feature.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Status of fs-successor-ids
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> > Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
>
> The BDB situation should be about the easiest scenario possible. I mean,
> it's a database, for crying out loud. My not-completely-thought-out
> approach would be: run a cursor over the whole `nodes' table, reading
> node-revision-ids (the keys of that table) and precessor-ids (parsed from
> the values of that table), and store the reverse mapping in the `successors'
> table.
In other words, run over the noderev-to-predecessor mapping and reverse
it. No argument about /that/. But do we make 'svnadmin upgrade' do
that, or do we introduce a bit that says "Set this bit to '1' after
you've built the successors mapping"?
Re: Status of fs-successor-ids
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
The BDB situation should be about the easiest scenario possible. I mean,
it's a database, for crying out loud. My not-completely-thought-out
approach would be: run a cursor over the whole `nodes' table, reading
node-revision-ids (the keys of that table) and precessor-ids (parsed from
the values of that table), and store the reverse mapping in the `successors'
table.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Status of fs-successor-ids
Posted by Daniel Shahaf <da...@elego.de>.
Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 13:52:13 -0400:
> On 09/13/2011 01:28 PM, Stefan Sperling wrote:
> > One other remaining item is in-place upgrades.
> > I'd like to optionally support in-place upgrades instead of requiring
> > users to dump/load.
>
> Yeah, this is a pretty important goal in my book. We've managed to go a
> looooong time without requiring dump/load from our admins[1]. To the degree
> possible, I'd like to continue that trend.
>
> -- C-Mike
>
> [1] ... sometimes requiring that we go well out of our way for their sake.
> Anyone remember the change of delta directions in the BDB backend?
>
Re: Status of fs-successor-ids
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 09/13/2011 01:28 PM, Stefan Sperling wrote:
> One other remaining item is in-place upgrades.
> I'd like to optionally support in-place upgrades instead of requiring
> users to dump/load.
Yeah, this is a pretty important goal in my book. We've managed to go a
looooong time without requiring dump/load from our admins[1]. To the degree
possible, I'd like to continue that trend.
-- C-Mike
[1] ... sometimes requiring that we go well out of our way for their sake.
Anyone remember the change of delta directions in the BDB backend?
Re: Status of fs-successor-ids
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Sperling wrote on Tue, Sep 13, 2011 at 19:28:01 +0200:
> I'd consider the branch done as soon as both backends store successors
> of each node-revision, and are able to return the list of immediate
> successors of a given node-revision. We must also have some basic unit
> tests to show that it works.
>
> At that point I'd like to merge into trunk and continue development there.
>
Works for me.
> > The branch doesn't have yet
> >
> > - consumers of these new APIs
>
> One other remaining item is in-place upgrades.
> I'd like to optionally support in-place upgrades instead of requiring
> users to dump/load.
I'll look into upgrades then.
For FSFS I imagine having an external tool to populate the cache --
i.e., format 6 will mean "/can/ have a successors cache", but there will
be an additional bit saying "the successors cache is up to date".
I'll also look into BDB, but I'm not sure offhand what to suggest there.
Re: Status of fs-successor-ids
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 13, 2011 at 06:02:44AM +0300, Daniel Shahaf wrote:
> The branch doesn't have code for answering questions such as
>
> - where were a given path's parents copied to?
> - when was a given path deleted?
> - (questions about merges)
> - (questions about a directory's properties having changed,
> as opposed to `something under that directory' having changed)
These are high-level questions that can be addressed after reintegrating
the branch.
I'd consider the branch done as soon as both backends store successors
of each node-revision, and are able to return the list of immediate
successors of a given node-revision. We must also have some basic unit
tests to show that it works.
At that point I'd like to merge into trunk and continue development there.
> The branch doesn't have yet
>
> - consumers of these new APIs
One other remaining item is in-place upgrades.
I'd like to optionally support in-place upgrades instead of requiring
users to dump/load.