| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reworked to allow "be comment" to handle unicode strings (see bug
e4ed63f6-9000-4d0b-98c3-487269140141). The solution was to escape all
the unicode to produce and ASCII string before calling
ElementTree.XML, and then converting back to unicode afterwards.
Added a unicode-containing comment to the end of bug
f7ccd916-b5c7-4890-a2e3-8c8ace17ae3a so that there's a handy unicode
comment for testing.
XML headers (e.g. '<?xml version="1.0" encoding="UTF-8" ?>') are
now added to all xml output from be.
Switched non-text/* encoding library to base64 instead of
email.encoders, which makes that code in libbe/comment.py simpler.
Changed libbe/mapfile.py error encoding from string_escape to
unicode_escape so it can handle unicode.
Everything's still untested, and be-xml-to-mbox doesn't handle unicode
yet, but I felt this commit was getting a bit unwieldy ;).
|
| |
|
|
|
|
|
|
|
|
|
| |
These didn't work with my update_copyright.sh.
I went with
Aaron Bentley and Panometrics, Inc.
instead of
Aaron Bentley <abentley@panoramicfeedback.com> and Panometrics, Inc.
just because of line length, but I'm open to convincing if people
prefer the latter...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Just return an empty dict instead.
Steps to reproduce:
$ mkdir /tmp/BE-test
$ cd /tmp/BE-test
$ be set-root
$ be new 'having too much fun'
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I adjusted the YAML format following
http://pyyaml.org/ticket/11
Unicode support
To remove '!!python/unicode' escapes and allow unicode in the output.
We can always have unicode in the output because the output is encoded
(as per the BugFile.encoding setting) before being sent to the outside
world.
|
| |
|
|
|
|
|
| |
They currently have no effect, but you can see them with
$ be set
There's a lot of information in this one 'settings' variable. I think
set will have to be specialized to handle arrays smoothly...
|
| |
|
|
|
| |
Now mapfile access has fewer special cases, and there is less
redundant rcs.add/update code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
They don't seem to be used anywhere...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
