| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
Also add `**kwargs` to `invoke` so we can specify the environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was in favor of always leaving _VERSION commented in the trunk,
since released branches should fork off the trunk:
trunkA -> trunkB -> trunkC -> trunkD
`-> 1.0.0 `-> 1.1.0
`-> 1.0.1 `-> 1.1.1
But that doesn't seem to have been how things have worked out in BE.
In any case, you will need to release on top of a previous release
(e.g. 1.0.1 on top of 1.0.0 in my above example), so we cannot depend
on an initial comment character before _VERSION.
|
| |
|
| |
|
|
|
|
| |
http://pypi.python.org/pypi/update-copyright/
|
| |
|
|
|
|
|
|
| |
So make failed for me (Matěj Cepl).
Signed-off-by: Matěj Cepl <mcepl@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Per gitignore(5) it seems to me that directories in the root of the
repository should be ignored without leading ./ files. E.g.
build/
is correct for ignoring build/ directory and its content.
Signed-off-by: Matěj Cepl <mcepl@redhat.com>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some temporary changes to encoding.py seem to have been added to
commit 1512c0e2a64e19c8d4e5697257a4df5ddd8bc727
Author: W. Trevor King <wking@drexel.edu>
Date: Tue Nov 8 07:14:43 2011 -0500
by accident.
The initial change came from discussions with Niall Douglas, during
which I realized that "filesystem encoding" ususally means the
encoding for the *path*, not the *contents*. To avoid further
confusion I'd renamed `get_filesystem_encoding` to the less ambiguous
`get_text_file_encoding`. This commit should complete the transition.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This catches the docs up with the changes made in:
commit a7ad89a6ad7da55089e6f9a4cdd645b7079ee04e
Author: W. Trevor King <wking@drexel.edu>
Date: Sat Apr 16 21:26:02 2011 -0400
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the changes for 1.9 brought in by
bb645f8e489b9f50cd0aec7237ec9adb721797a8
optional. If the Mercurial version is 1.9 or greater, the new code is
used. Otherwise, the old code is used.
|
| | |
| | |
| | |
| | | |
The version comparison code will be useful for all VCSs.
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
change to command.base.UnknownCommand in commit 0d5c9c68e947617c9d073d5f19351bdd8f3866db
|
| | | |
| | | |
| | | |
| | | | |
(mercurial.dispatch.dispatch() now takes a single request object with option for capturing output stream)
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bzr uses non-numeric tags to indicate prereleases; previously, this
triggers an exception in be's Bzr module as version comparison is only
supported between version strings that only contain numbers and dots.
This patch extends version_cmp to support a single non-numeric
pre-release string of arbitrary length (e.g. 'a', 'b', 'pre', 'rc'), and
extends the docstring tests to cover this extension.
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This catches the test result up after:
Commit: 0d5c9c68e947617c9d073d5f19351bdd8f3866db
Author: W. Trevor King <wking@drexel.edu>
Date: Wed May 25 10:30:19 2011 -0400
Attach ImportError message to UnknownCommand to aid debugging.
|
| |/ /
| | |
| | |
| | | |
testing.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the user doesn't provide the summary on the command line, through
stdin, or through editor_string, raise an error. This will generally
happen with
$ be commit
(user doesn't enter any text in the editory)
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Now you can run `be commit` with no options and have the summary split
off the body automatically. This should be more familiar to most VCS
users.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Because "be set severity blah" does not actually work, referring users
there to set custom severity levels is just cruel (I spent a half hour
trying to figure out what I was doing wrong). Thus, it is much easier
to, at least for now, state in the help message what they must do in
order to get custom severities and statuses.
|
| |
| |
| |
| |
| |
| | |
Again, there is discrepancy between severity.py and status.py. I thought
this feature was extremely useful in severity.py and it should be put
into status.py too.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code structure was vastly different in severity.py to status.py, so
I mostly copied the structure from there and adjusted it to suit
severity.
The structure in status.py looked (to me) cleaner, more organised, and
easier to work with.
Also, users are now referred by "be severity --help" to "be set --help",
in a manner similar to "be status --help".
For those that don't know that severity can be adjusted on a per
repository basis, this seems extremely helpful. A similar message
appears for status, but not here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|