A partial bundle is created to temporarily save revisions > rev but
not descending from the node to strip, to be able to restore the
changesets after stripping the changelog.
Since this bundle is not kept after the strip operation, and is not
user-visible, it is not necessary and should be faster to avoid
compression.
The three replace calls are slower than this simple __contains__,
and anyway we should not have this many paths ending with .i, .d, or .hg
compared to the normal, un-encoded other paths.
This patch implement a fixer that replaces all calls to the '%' when bytes
arguments are used to a call to bytesformatter(), a function that knows how to
format byte strings. As one can't be sure if a formatting call is done when
only variables are used in a '%' call, these calls are also translated. The
bytesformatter, in runtime, makes sure to return the "raw" % operation if
that's what was intended.
This patch adds some ugly constructs. The first of them is bytesformatter, a
function that formats strings like when '%' is called. The main motivation for
this function is py3k's strange behavior:
>>> 'foo %s' % b'bar'
"foo b'bar'"
>>> b'foo %s' % b'bar'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'bytes' and 'bytes'
>>> b'foo %s' % 'bar'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'bytes' and 'str'
In other words, if we can't format bytes with bytes, and recall that all
mercurial strings will be converted by a fixer, then things will break badly if
we don't take a similar approach.
The other addition with this patch is that the os.environ dictionary is
monkeypatched to have bytes items. Hopefully this won't be needed in the
future, as python 3.2 might get a os.environb dictionary that holds bytes
items.
This patch implements a 2to3 fixer that converts all plain strings in a python
source file to byte strings syntax. Example:
foo = 'Normal string'
would become
foo = b'Normal string'
The motivation behind this fixer can be found in
http://selenic.com/pipermail/mercurial-devel/2010-June/022363.html or, in other
words: the current hg source assumes that _most_ strings are "meant" to be byte
sequences, so it makes sense to make the convertion implemented by this patch.
As mentioned above, not all mercurial modules want to use strings as bytes,
examples include i18n (which uses unicode), and demandimport (in py3k, module
names are normal strings, thus unicode, and there's no need for a convertion).
Therefore, these modules are blacklisted in the fixer. There are also a few
functions that can take only unicode arguments, thus the convertion shouldn't
be done for those.
This patch implements a script that inherits most of its functionality from
hg's setup.py and adds support to calling 2to3 during invocation with python3.
The motivation of having this script around is twofold:
1) It enables py3k crazies to test mercurial in py3k and, hopefully, patch it
more easily, so it can improve the py3k support to eventually run there.
2) Being separated from the main setup.py eliminates the need to make hg's
setup.py even more cluttered, and enables "independent" development until
the port is done.
Some considerations about the structure of this patch:
Mercurial already overrides the behavior of build_py, this patch tweaks it a bit
more to add support to call 2to3 with a custom fixer* location for Mercurial.
There is also a need of having the core C modules built *before* the
translation process starts, otherwise 2to3 will think those are global modules.
* A fixer is a python module that transforms python 2.x code in python 3.x
code.
Currently, if you start editing a commit message from qrefresh -e and, for any
reason: forget you were editing it, leave the editor open and start qpopping
and qpushing, when you decide to save your commit message, it is going to fail.
This patch copies the commit behavior of saving the message contents in
$HGROOT/.hg/last-message.txt before continuing.
The following patch allows the use of python2.4 with a standalone
hashlib rather than assuming that python2.5 is in use when hashlib is
imported successfully.
A query like
head() and (descendants("bad") and not descendants("fix"))
(testing if repo heads are affected by a bug) will abort with a
RepoLookupError if either badrev or fixrev aren't found inside
the repository, which is not very informative.
The new predicate returns an empty set for lookup errors, so
head() and (descendants(present("bad")) and not descendants(present("fix")))
will behave as wanted even if those revisions are not found.
The 'level' argument to __import__ was added in Python 2.6, and is
specified for either relative or absolute imports. The fix introduced
in 5b0fda8ff209 allowed such imports to proceed without failure, but
effectively disabled demandimport for them. This is particularly
unfortunate in Python 3.x, where *all* imports are either relative or
absolute.
The solution introduced here is to store the level argument on the
demandimport instance, and propagate it to _origimport() when its
value isn't None.
Please note that this patch hasn't been tested in Python 3.x, and thus
may not be complete. I'm worried about how sub-imports are handled; I
don't know what they are, or whether the level argument should be
modified for them. I've added 'TODO' notes to these cases; hopefully,
someone more knowledgable of these issues will deal with them.
If you want to programatically perform a revert right now you need to
include a date=False parameter due to the use of opt["date"] instead
of opt.get("date").
