| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously "message[<some-attr>]" just returned None if it wasn't set
for that message part, which overwrote anything passed in through
fields.
"from" and "date" added to list of attributes passed along.
For be-xml-to-mbox, "alt-id" was added to Comment._attrs,
and Comment.print_to_mbox was adjusted to handle the case where
we have no information about the parent bug.
With all of this, I can complete the loop
be-mbox-to-xml example.mbox | be-xml-to-mbox > example2.mbox
without errors :p.
Finally, be-xml-to-mbox has been adjusted to also work on files (it
had previously only handled data via stdin). We can't add stdin
handling to be-mbox-to-xml though, because the mailbox package needs
an actual file to work on, and I haven't setup a tmpfile workaround
yet...
|
| |
|
|
|
|
| |
Now it runs off xml.etree instead of xml.sax.
Removed "No matching bugs found" from "be list --xml" output.
|
| | |
|
| |
|
|
|
|
| |
ElementTree.XML was choking on them. I should unescape all whitespace
(e.g. tabs, etc.), but I'm lazy and don't have any XML that's strange
enough to need it ;).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ;).
|
| |
|
|
|
|
| |
Found a few that were actually "fixed" and one that I reopened.
Perhaps we should add a "merged" status to the default, so that the
merged bugs don't clutter up the closed bugs category...
|
| |
|
|
|
|
|
|
|
| |
I don't really like the "defaults to None" for the settings that have
funky initialization procedures (most of them :p), but I'm not sure
how to handle that cleanly yet. Perhaps
be set --current
I also need to find a method of adding complicated settings like the
nested lists for severities, etc from the "be set" commandline.
|
| |
|
|
|
|
|
|
|
|
|
| |
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...
|
| | |
|
| |
|
|
|
| |
Also adjusted libbe/comment.py to move to user-specified alt_ids,
rather than uuids.
|
| |
|
|
|
|
| |
Now the behavior conforms to the docstring:
If both default and generator are None, then the property will be a
defaulting property which defaults to None.
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
It doesn't matter now, but at some point Bugdir might implement some
sort of repo-wide caching which would need to be saved. The
BugDir.save() method should be intelligent enough to not save things
that have not changed, so efficiency should not be effected either.
|
| |/
|
|
|
|
|
|
|
|
| |
Removed superfluous nesting in ./be's error catching. Also replaced
KeyErrors due to unknown commands with the more specific
cmdutil.UnknownCommand, since all sorts of programming errors can
raise KeyErrors.
Untested, since my working tree is a mess at the moment, but what
could go wrong? ;)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Following Ben's Wed, 01 Jul 2009 11:31:51 +1000 suggestion.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
On the advice of
Martin F Krafft <madduck@debian.org>
as posted in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477125
on
Fri, 12 Jun 2009 17:03:02 +0200
|
| |
|
|
|
| |
Previously it choked when options.content_type == None.
I'm not sure how that made it past test_usage.sh...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I don't know much darcs, so I make no claims about the beauty of my
implementation. It seems to get the job done though, until a darcs
guru comes along.
I also tweaked the libbe.git.Git._rcs_get_user_id to handle the case
where user.name or user.email are not set.
I also added the option to pass a stdin string into the
libbe.rcs.RCS._u_invoke* functions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main problem was the encoding/decoding that was happening to _all_
input/output. Now many I/O activities have a `binary' option to
disable any encoding/decoding. The `binary' flag is set whenever the
comment content-type is not a text/* type.
In order to print valid XML (and make life easy on xml/be-xml-to-mbox),
non text/* types are printed out as base64-encoded MIME messages, so
be list --xml | be-xml-to-mbox | catmutt
works as you'd expect.
With the standard (non-XML) output from `be show', we just print a
message telling the user that we can't reasonably display the MIME
type and that they should use the XML output if they want to see it.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This makes all the failed tests understandable, since they all crash
with strings like:
AssertionError: Arch RCS not found
Which makes more sense than spitting out the raw CommandError.
It also means that installed_rcs() actually works now ;).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This closes bug 7ec2c071-9630-42b0-b08a-9854616f9144. BE is now bug
free ;). At least until the next commit :p.
Writing depend.py turned up a few style points in tag.py which I also
fixed.
|
| | |
| |
| |
| |
| | |
Loading all the bugs for the list search had the side effect of
updating all the bug values files to the new YAML format.
|
| | |
| |
| |
| |
| | |
Now you can limit your list to bugs matching certain extra strings,
e.g. "TAG:working".
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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'
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
extra_strings returns to a defaulting property from a cached/generator
property, with the help of the new, mutable defaults. Lots of
deepcopies avoid mutable default uncertainty too ;). And
copy.deepcopy([]) should be pretty cheap.
tag --remove had previously left settings["extra_strings"] as [],
which polluted the bug's values file. Now the improved
defaulting_property notices a return to the default [], and sets the
internally stored value to EMPTY.
I struggled with creating a more intuitive way to notice changes to
extra_strings than the
tmp = bug.extra_strings
<work on tmp>
bug.extra_strings = tmp
but didn't have any luck. The problem seems to be that if you only
hand out copies of your default, you don't have any pointers to what
you handed out to check for changes. On the other hand, if you hand
out your original default, any external changes will _change_ your
original default. I suppose you could only hand out copies, but keep
a list of all copies handed out, but that sounds like a disaster.
Reassigning is easy enough.
|
| | |
| |
| |
| | |
This avoids the problems associated with mutable defaults.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This continues the line of changes started in libbe/properties with
the last two commits. Also straightened up stranch double-default in
libbe.settings_object.versioned_property and moved the fn_checked
before checked, which shouldn't matter because I never use both at
once, and can't think of a case where you'd want to.
I've also added some docstrings to the settings_object unit tests,
since apparently docstrings get printed during the test if they exist,
and they look nicer than the name of the unittest itself. More like
./configure output ;).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now (except for a wimpy hash function) it's as good as it's going to
get for true mutables. Calls to change_hook occur for all changes,
sometime after the change-enducing action and before the next
attribute access. See testChangeHookMutableProperty for an example of
the expected behavior.
If you're doing some mutable-modification (e.g. t.x.append(5)) and you
want to `flush' the changes into a change_hook call, just assign t.x
to a dummy variable. e.g.
t.x.append(5)
dummy = t.x
If you _really_ need post-modification change_hook calls without such
a flush, you're on your own. Would you get the property-owning class
to poll for changes?
|
| | |
| |
| |
| |
| | |
Oops, I forgot to add becommands/tag.py with my last commit. Here it
is now, with the added ability to remove tags.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Versioned properties whose data is a mutable type are tricky, since
the simple comparisons we'd been using in
libbe.properties.change_hook_property don't work for mutables. For
now, we avoid that problem by assuming a change happened whenever a
mutable property is set. change_hook_property is a bit untidy at the
moment while I work out how to deal with mutables.
As an example of using Bug.extra_strings to patch on some useful
functionality, I've written becommands/tag.py. I'd suggest future
add-ons (e.g. becommands/depend.py?) use the "<LABEL>:<value>" string
format to keep it easy to sort out which strings belong to which
add-ons. tag.py is still missing command line tag-removal and
tag-searching for `be list'. Perhaps something like
be list --extra-strings TAG:<your-tag>,TAG:<another-tag>,DEPEND:<bug-id>
would be good, although it would requre escaping commas from the tags,
or refusing to allow commas in the tags...
libbe.properties.ValueCheckError also got a minor update so the
printed error message makes sense when raised with allowed being an
iterable (i.e. check_property) or a function
(e.g. fn_checked_property).
All of this digging around turned up a really buggy
libbe.bugdir.MultipleBugMatches. Obviously I had never actually
called it before :p. Should be fixed now.
libbe.comment._set_comment_body has also been normalized to match the
suggested change_hook interface: change_hook(self, old, new).
Although, I'm not sure why it hadn't been causing obvious problems
before, so maybe I'm misunderstanding something about that.
|
| |\ \ |
|
| | | | |
|
| | | | |
|
