[PATCH] TreeConfig should support sections

[Jan Balster]

John Arbash Meinel wrote:
> Jan Balster wrote:
>>> The attached bundle contains a patch for bzrlib/config.py:TreeConfig.get_option
>>> and two tests.
>>>
>>> If a section was specified the value for a key was not searched in the section.
>>>
>>> Jan
> 
> ...
> 
>>> === modified file bzrlib/tests/test_config.py
>>> --- bzrlib/tests/test_config.py
>>> +++ bzrlib/tests/test_config.py
>>> @@ -118,6 +118,9 @@
>>>      def lock_write(self):
>>>          pass
>>>  
>>> +    def lock_read(self):
>>> +        pass
>>> +
>>>      def unlock(self):
>>>          pass
> 
> ^- this fix seems unrelated. Is there a reason you had to add it?

TreeConfig calls this method on a branch, so I added it to FakeBranch.

>>>  
>>> @@ -818,6 +821,24 @@
>>>                                        location='http://example.com/specific')
>>>          self.assertEqual(my_config.get_user_option('option'), 'exact')
>>>  
>>> +class TestTreeConfig(TestCaseInTempDir):
>>> +
>>> +    def test_toplevel_key(self):
>>> +        branch = FakeBranch(user_id='Robert Collins <robertc at example.net>')
>>> +        my_config = config.TreeConfig(branch)
>>> +        my_config.set_option('myvalue', 'myname')
>>> +        self.assertEqual(my_config.get_option('myname', default='default_value'),
>>> +                         'myvalue')
>>> +        
>>> +
>>> +    def test_supports_sections(self):
>>> +        branch = FakeBranch(user_id='Robert Collins <robertc at example.net>')
>>> +        my_config = config.TreeConfig(branch)
>>> +        my_config.set_option('myvalue', 'myname', 'mysection')
>>> +        self.assertEqual(my_config.get_option('myname', 'mysection',
>>> +                                              'default_value'), 'myvalue')
> 
> I think it is reasonable to fix this, since our API claims to support
> having sections. I know Robert has voiced some concerns about how
> sections will propagate, etc. But I think it is better to have the API
> do what it says it does, and then we can decide whether we need to
> change the API.
> 
> So +1 from me.
> 
> John
> =:->