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 BD
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
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
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
long time without requiring dum
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
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
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 instea
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 cha
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
9 matches
Mail list logo