| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Only one live bug left:
7ec2c071-9630-42b0-b08a-9854616f9144
I've decided (mostly due to the huge Trac post, see bug comments) to
_not_ hardcode dependencies, but to add an attribute-creation
mechanism that a becommand/depend.py could use for dependency
tracking. Time for a new branch to think this out...
|
|
|
|
|
|
|
|
|
|
|
| |
Also added libbe.bug.cmp_last_modified, which handles part of
9ce2f015-8ea0-43a5-a03d-fc36f6d202fe. To do better we could extend
the RCS framework.
I also transcribed a few emails from the be-devel list onto their
relavent bugs and closed a few bugs.
Finally, I removed some left over InvalidValue cruft.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Converts the output of `be list --xml` mbox format.
For example:
$ be list --xml | be-xml-to-mbox | catmutt
|
| | |
|
| |
| |
| |
| |
| |
| | |
Since
<creator>John Doe <jdoe@example.com></creator>
is not valid XML.
|
| | |
|
| |
| |
| |
| | |
The xml() method hadn't been updated since the settings_object revamp.
|
| |
| |
| |
| |
| | |
Renamed "name" -> "short-name" and "in_reply_to" -> "in-reply-to".
Reordered uuid before short-name.
|
| |
| |
| |
| |
| |
| | |
Now
$ cat example.mbox | catmutt
works. Onwards to be-xml-to-mbox!
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The goal is to turn grepm into catmutt, and end up with
$ be --xml list | be-xml-to-mbox | catmutt
to browse current bugs and comments in mutt.
Moritz has generously donated grepm under GPLv2. Not GPLv>=2 yet, so
if the project decides to go to GLPv3 for example, this file will have
to stay behind. Not that I see such a change coming, but I thought it
was worth commenting on, so we don't forget.
|
|/
|
|
| |
Following Chris' advice. Don't know what I was thinking before ;).
|
| |
|
|
|
|
|
|
|
|
| |
Oops. I seem to have removed it in my Thu 2008-11-27 19:35:55 -0500
commit. Luckily, the version I removed was still sitting right were
it belongs as
/etc/bash_completion.d/be
Now it will be back in the tree.
|
|
|
|
|
|
|
|
| |
Another bug introduced by James Rowe's user-config patch. Obviously
it's hard to read a file if there's no file there. I'm not sure how
it passed the unit tests earlier. Maybe I forgot to install the
pre-commit version before running the test suite... Anyhow, fixed
now.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This involved an `upgrade' of BE's bzr repo
Previous version (via `bzr info path/to/repo`): pack-0.92
Current version: rich-root-pack
The whole rich-root thing is a bzr features-vs-backwards-compatability
thing they've been wrestling with [1,2,3,4,...]. It seems that BE was
in some sort of unstable equilibrium [5], so I'll follow Ben's lead
and make the official switch. Note that you'll need to use bzr>=1.5
to make the shift [6]. For the sake of completeness, the whole
rich-root thing was introduced here [7], but I don't understand enough
of bzr to make sense of the diff. It just versions the repo's root
directory the same way it versions other directories [3]. The bzr
people seem to be planning to phase out non-rich-root formats in favor
of brisbane-core, aka 2.0beta [8], by bzr 2.0 [8], which is apparently
on the horizon [9,10,11]. What a headache.
Citations are all titles/X-List-Received-Date from
https://lists.ubuntu.com/archives/bazaar/
with the exception of the URL [11].
[1] [RFC] rich root pack as default in 1.8 ?
Sat, 06 Sep 2008 03:33:46 -0000
(conclusion: none)
[2] Re: 1.9rc1 countdown
Thu, 30 Oct 2008 08:44:53 -0000
(conclusion: "primary" format should be rich-root next time we make a new format)
[3] So many repo formats
Fri, 14 Nov 2008 08:41:33 -0000
Mon, 17 Nov 2008 07:37:47 -0000 (explains rich-root format)
Mon, 17 Nov 2008 22:37:39 -0000 (explains no-return policy)
Mon, 17 Nov 2008 20:57:08 -0000 (explicitly lists non-svn reasons for rich-root)
[4] Branch fails from 'pack-0.92' repo to 'rich-root-pack' repo.
Wed, 27 Aug 2008 11:31:11 -0000
(we're not sure again)
[5] Branch fails from 'pack-0.92' repo to 'rich-root-pack' repo.
Sun, 20 Apr 2008 12:58:09 -0000
[6] Branch fails from 'pack-0.92' repo to 'rich-root-pack' repo.
Fri, 29 Aug 2008 13:23:52 -0000
[7] [RFC] Knit format 2
Fri, 25 Aug 2006 22:55:36 -0000
[8] bazaar 2.0beta format for launchpad release
Fri, 29 May 2009 06:00:03 -0000
[9] Upgrading loggerhead to 1.9-rich-root
Mon, 11 May 2009 22:35:28 -0000
(mentions eventual switch to rich-root in 2.0)
[10] bzr 1.16rc1 released!
Fri, 12 Jun 2009 08:00:08 -0000
(confirms eventual switch to rich-root in 2.0)
[11] https://launchpad.net/bzr/+announcement/2733
(current outstanding releases: 1.17, 2.0)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| | |
$ be list --invalid-option | be comment <bug-id> -
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes bug introduced by James Rowe's previous patch:
$ be list
Traceback (most recent call last):
...
File ".../libbe/rcs.py", line 34, in _get_matching_rcs
import arch
File ".../libbe/arch.py", line 29, in <module>
client = config.get_val("arch_client")
File ".../libbe/config.py", line 70, in get_val
File "/usr/lib/python2.5/codecs.py", line 817, in open
file = __builtin__.open(filename, mode, buffering)
IOError: [Errno 2] No such file or directory: '/home/wking/.bugs_everywhere'
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
From his email to the be-devel list:
From: James Rowe <jnrowe@ukfsn.org>
Date: Tue, 3 May 2009 11:44:41 +0000
Subject: [PATCH] Don't create config file unless we're using arch.
Hi,
I find the current behaviour of creating a config file simply to set
a default for a revision control system I'm never going to use to be
a little annoying, the attached patch changes this behaviour to only
set the default in the config file if you're actually using arch.
Thanks,
James
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I rewrote a few of his routines, e.g. generalizing
Comment.string_thread to run a caller-specified method avoided the
need for some duplicate code in Comment.xml_thread. There was also a
reasonable reorganization of libbe.settings_object.versioned_property
because the <in_reply_to> field of the Comment.xml output was giving
me `-1' (= old settings_object.EMPTY) instead of None, even after I
had set comm.in_reply_to to None. The rewritten versioned_property
avoids the ambiguity of UNPRIMED vs EMPTY, and avoids the stupididy of
my using EMPTY=-1 ;).
|
| |/ |
|
| | |
|
|\ \ |
|
| |/ |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
9a942b1d-a3b5-441d-8aef-b844700e1efa
Aaron says it's already implemented in the Bugs-Everywhere-Web, and
$ be show `be list --status all --uuids` | grep -A5 -B5 XYZ
works pretty well for me on the command line.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The new setting is currently only used when creating new bugs with
becommand/new.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If bug_A had no comments (and so, no comment directory), changing
comment settings before saving raised missing directory errors.
save_settings had previously assumed the
.be/bugs/XYZ/comments/
directory existed, which wasn't true for comment-less bugs. Now it
checks, and creates the directory if necessary.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 severity levels working.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
becommands/severity gets the configured settings appropriately.
Todo:
adjust setting-validation to compare against the current values.
setup becommands/severity to --complete severities.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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...
|
| | | |
|
| | |
| | |
| | |
| | | |
Closes e2f6514c-5f9f-4734-a537-daf3fbe7e9a0
|
|\ \ \ |
|