bzr svn propedit equivalent

[Kent Gibson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>
>>> Other bits I'd like to see include a get --all and/or having that as
>>> the default if no option is specified.
>>>     
>
> this is a bit more complicated, due to having several config stores
>
I didn't say it would be easy, just that I'd like to see it ;-).

>>> I'd also like a sub command to remove an option from a config file,
>>> say remove or reset.
>>> e.g. bzr config --location reset email
>>>     
>
> again, complicated; I'll have to subclass BranchConfig for the 2
> above features, because there is no "dump" and "remove" functionality
>
Rather than subclassing, I'd consider adding the functionality to the
bzr classes themselves.

>> It's better to stay in same commands sa bzr itself; "remove" and alias
>> "rm":
>>
>>     $ bzr config rm [option] {variable}
>>
>> Possible options:
>>
>>     --all           remove all
>>     --regex=RE      Remove variables by regexp RE
I think applying regexes to this application is massive overkill - the
names of the config options are well known after all.  If you want to
selectively delete a bunch of them do it by naming them explicitly.

Remember you want to test all this, so try to keep the down the what
you really need.
 
>
> unless there is some class I don't know about (quite possible,
> actually), there is no support for subcommands with specific options
> and aliases, so this would need to be implemented by hand; and it'll
> grow big, and I'm horrified about writing tests, because I've never
> done that (never needed), so I wouldn't know where to start and
> where to finish :)
>
I agree about the subcommand options and aliases, so I would try to
avoid them if you can.
I'm not big on builtin aliases anyway - the user can add their own to
bazaar.conf if they want.
I'd only use them where there is a direct parallel to another VCS and
you are trying to ease migration.
Wrt options, the only one I had suggested was get --all, and even that
you could do without - just make "bzr config get" default to all.


I haven't worked on any plugins myself, but using Aaron's bzrtools as
a guide, the tests for plugins follow a similar structure to those in
bzr itself - add a tests directory and add your test cases there.
You can find examples of test cases for the existing bzr commands in
the bzr code tree (in bzrlib/tests/).

As to what tests to write, there are two types of tests I'd write -
positive and negative.
The positive are the cases where everything works as expected.
The negative are the cases where something goes wrong and confirm that
you handle the case without falling in a heap.

For the config commands I'd add positive test cases for each
subcommand, and where appropriate operating on each config file.
These tests demonstrate that the get/set/remove config options work as
advertised.
The negative cases that spring to mind are removing non-existent
config options, operating on non-existent config files, and operation
outside a working tree.
That's probably not complete, but you can always add tests for
additional corner cases as they come up.

The biggest problem I can think of is that you don't want your tests
to operate on the real config files.  I think test_config.py provides
an example of how to dummy that.


Cheers,
Kent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF66FMgoxTFTi1P8QRAgHkAKDLlICrlKib1zAG8O+efzkfp+JYKACcDCcD
BQdirexF+268gP4ILFcZxtE=
=Se5J
-----END PGP SIGNATURE-----