aboutsummaryrefslogtreecommitdiffstats
path: root/becommands/status.py
Commit message (Collapse)AuthorAgeFilesLines
* Merged with Trevor's -rr branchGianluca Montecchi2009-10-021-9/+12
|
* Merged with head branchGianluca Montecchi2009-10-011-25/+38
|
* Updated copyright blurbs and AUTHORS and included script for future updatesW. Trevor King2009-07-011-1/+1
|
* becommands/severity and status now handle --complete appropriately.W. Trevor King2008-12-041-5/+26
| | | | | | | | | | I also disabled interspersed options and arguments in cmdutils.CmdOptionParser. See http://docs.python.org/library/optparse.html Now $ be severity xyz --complete returns available severities. It had previously returned --help --complete
* Per-tree status levels working.W. Trevor King2008-12-041-11/+14
|
* Added bugid_args option to cmdutil.default_complete.W. Trevor King2008-11-271-1/+2
| | | | | | | | Now most of the bug-id arguments support Bash completion. Since there will hopefully be lots of bugs in the database, I decided to filter the list of available bugs. Currently, we just auto-complete active bugs for most commands, with the exceptions of open (obviously) and status (which needs to work on all types of bugs).
* Command completion simplified and working for list, dummies for other cmds.W. Trevor King2008-11-271-1/+3
| | | | | | | | All the other commands currently use default_complete(), which has no effect other than catching the --complete option and effectively aborting execution. This closes 8e1bbda4-35b6-4579-849d-117b1596ee99
* Added libbe/encoding.py to wrap input/output/file access appropriately.W. Trevor King2008-11-251-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I borrowed most of the code for this. get_encoding() is from Trac http://trac.edgewall.org/browser/trunk/trac/util/datefmt.py format_datetime() Trac has a BSD license http://trac.edgewall.org/wiki/TracLicense I don't know if such a small snippet requires us to "reproduce the above copyright" or where we need to reproduce it if it is needed. The stdout/stdin replacement code follows http://wiki.python.org/moin/ShellRedirectionFails Because of the stdout replacement, the doctests executes now need an optional 'test' argument to turn off replacement during the doctests, otherwise doctest flips out (since it had set up stdout to catch output, and then we clobbered it's setup). References: http://wiki.python.org/moin/Unicode http://www.amk.ca/python/howto/unicode http://www.python.org/dev/peps/pep-0100/ I also split libbe/editor.py off from libbe.utility.py and started explaining the motivation for the BugDir init flags in it's docstring.
* Tweaked usage strings to increase consistency. Also added README.dev.W. Trevor King2008-11-241-1/+1
| | | | I tried to stick to CAPS for argument placeholders.
* Go back to lazy bug loading to get execution speed back up.W. Trevor King2008-11-231-1/+1
| | | | Fixes bug b3c6da51-3a30-42c9-8c75-587c7a1705c5
* Another major rewrite. Now BugDir, Bug, and Comment are more distinct.W. Trevor King2008-11-211-8/+7
| | | | | | | | | | | | | | | I pushed a lot of the little helper functions into the main classes, which makes it easier for me to keep track of what's going on. I'm now at the point where I can run through `python test.py` with each of the backends (by changing the search order in rcs.py _get_matching_rcs) without any unexpected errors for each backend (except Arch). I can also run `test_usage.sh` without non-Arch errors either. However, don't consider this a stable commit yet. The bzr backend is *really*slow*, and the other's aren't blazingly fast either. I think I'm rewriting the entire database every time I save it :p. Still, it passes the checks. and I don't like it when zounds of changes build up.
* Major rewrite of RCS backends. RCS now represented as a class.W. Trevor King2008-11-181-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lots of changes and just one commit. This started with bug dac91856-cb6a-4f69-8c03-38ff0b29aab2, when I noticed that new bugs were not being added appropriately with the Git backend. I'd been working with Git trouble before with bug 0cad2ac6-76ef-4a88-abdf-b2e02de76f5c, and decided things would be better off if I just scrapped the current RCS architecture and went to a more object oriented setup. So I did. It's not clear how to add support for an RCS backend: * Create a new module that - defines an inheritor of rsc.RCS, overriding the _rcs_*() methods - provide a new() function for instantizating the new class - defines an inheritor of rcs.RCStestCase, overiding the Class attribute - defines 'suite' a unittest.TestSuite testing the module * Add your new module to the rest in rcs._get_matching_rcs() * Add your new module to the rest in libbe/tests.py Although I'm not sure libbe/tests.py is still usefull. The new framework clears out a bunch of hackery that used to be involved with supporting becommands/diff.py. There's still room for progress though. While implementing the new verision, I moved the testing framework over from doctest to a doctest/unittest combination. Longer tests that don't demonstrate a function's usage should be moved to unittests at the end of the module, since unittest has better support for setup/teardown, etc. The new framework also revealed some underimplented backends, most notably arch. These backends have now been fixed. I also tweaked the test_usage.sh script to run through all the backends if it is called with no arguments. The fix for the dac bug turned out to be an unflushed file write :p.
* Split Bug and Comment class out to bug.py from bugdir.pyW. Trevor King2008-11-141-0/+75
Comment should probably have it's own file too... I also tried to clean up the interface for setting status and severity. Both attributes involve selecting strings from predefined lists. The lists of valid strings (and descriptions of each string) are now defined in bug.py. The bug.py lists are then used to generate appropriate help strings in becommands/status.py and severity.py. This should make it easier to keep the help strings in synch with the validation information. The original status strings weren't documented, and I didn't know what they all ment, so I elimanted some of them. 'in-progress' and 'disabled' are no longer with us. Of course, it would be simple to add them back in if people don't agree with me on that. Due to the loss of 'disabled' I had to change the status of two bugs (11e and 597) to 'closed'. I removed becommands/inprogress.py as well. It's functionality was replaced by the more general status.py command, which mimics the severity.py command.