This will allow us to start moving some of the nested functions inside verify()
out onto the class.
This will allow extensions to hook into verify more easily.
In order to allow extensions to hook into the verification logic more easily, we
need to refactor it into multiple functions. The first step is to move it to a
class so the shared state can be more easily accessed.
This patch makes hg log <file|folder> faster by using changelog.readfiles
instead of changelog.read.
On our large repos for hg log <file|folder> -l5 operations that were taking:
- ~8s I see a 25% improvement
- ~15s, I see a 35% improvement
For recently modified folder/file, the difference is negligible as we don't
have to consider many revisions.
This patch adds a new method "readfiles" to get the files modified by a
changeset. It extracts some logic from "read" to only return the files modified
by a changeset as efficiently as possible. This is used in the next patch to
speed up hg log <file|folder>
Revlogs were recently refactored to open file handles in "a+" and use a
persistent file handle for reading and writing. This drastically
reduced the number of file handles being opened.
Unfortunately, it appears that some versions of Solaris lose the file
offset when performing a write after the handle has been seeked.
The simplest workaround is to seek to EOF on files opened in a+ mode
before writing to them, which is what this patch does.
Ideally, this code would exist in the vfs layer. However, this would
require creating a proxy class for file objects in order to provide a
custom implementation of write(). This would add overhead. Since
revlogs are the only files we open in a+ mode, the one-off workaround
in revlog.py should be sufficient.
This patch appears to have little to no impact on performance on my
Linux machine.
Without this, the test fails with:
$ hg -q commit -A -m 'add pushurl'
abort: file:// URLs can only refer to localhost
$ hg push
abort: file:// URLs can only refer to localhost
The variable $PWD causes check-code to complain, so avoid that.
I'm not entirely happy with using a trailing / on a "file" entry for
transferring a treemanifest. We've discussed putting some flags on
each file header[0], but I'm unconvinced that's actually any better:
if we were going to add another feature to the cg format we'd still be
doing a version bump anyway to cg4, so I'm inclined to not spend time
coming up with a more sophisticated format until we actually know what
the next feature we want to stuff in a changegroup will be.
Test changes outside test-treemanifest.t are only due to the new CG3
bundlecap showing up in the wire protocol.
Many thanks to adgar@google.com and martinvonz@google.com for helping
me with various odd corners of the changegroup and treemanifest API.
0: It's not hard refactoring, nor is it a lot of work. I'm just
disinclined to do speculative work when it's not clear what the
customer would actually be.
This means that the diff code does less work, potentially
significantly less in the case of treemanifests. It also should ease
implementation with narrowed clone cases (such as narrowhg) when we
don't always have the entire set of treemanifest revlogs locally.
As far as I can tell, this codepath is currently only used by record,
so it'll probably die in the near future, and then narrowhg won't have
to worry about composing with some unknown matching system.
It made output order unpredictable because two separate buffers are flushed
individually. Let's use a thin wrapper that just sends close() to black hole.
It was introduced at fa80944106df, where "template" argument could be a file
object. After that, 426525670e45 added "len(template)", so "template" must be
a string now. Therefore, "fp != template" should always be True.
It seems fa80944106df was intended to work around a bug in TortoiseHg, and
I'm sure I've fixed it completely in TortoiseHg source.
https://selenic.com/pipermail/mercurial-devel/2011-February/028467.html
Because makefileobj() duplicates or wraps stdout, "fp != sys.stdout" didn't
work correctly. Python doc states that special file objects are named in the
form '<...>', and absolute filenames should never start with '<', we can
ignore names start with '<'. We can't test fp.fileno() because fp may be a
command-server channel.
https://docs.python.org/2.7/library/stdtypes.html#file.name
In the test output, "exporting patch:" line is printed after patch content.
This is caused by fdopen() and will be fixed by the subsequent patch.
Because unknown attributes are delegated to the underlying file object,
commandserver channels said they were '<stdout>' or '<stdin>' even though
they weren't. This patch makes them say '<X-channel>'.
The default behaviour to forbid this makes a lot of sense for novice users
because it's safeguarding them from dangerous behavior but making it
configurable will be apprieciated by power users in at least one big
organization.
It allows an user to look an histedit rules from declarative perspective and
make the rules reflect the state after histedit. If we can move lines t move
commits why can't we drop lines to drop commits?
Let's put this behind config knob and inform users about this feature the very
moment they are trying to use it so they can choose desired behaviour.
The diff output without binaries is definitely great for interactive users - a
binary patch is not meaningful for them. Although setting diff.nobinary flag
can break the automation. Let's force full output for automation.
Rather than sleep for 2 seconds, we sleep until the next even-numbered
second, which has the same effect, but makes tests faster. This
removes test-largefiles-update as the long pole of the test suite.