There are two other unrelated failures in this test. For some reason child1 has
a space after it, thus 2 spaces before the glob, otherwise the glob is ignored
and removed.
Before this, if a localizer/localization included a multiline
message, and didn't prefix the intermediate lines with 'HG: ',
then the line would be a candidate for inclusion in the commit
message -- which isn't ideal.
This regressed in f07f4c45a8f2, when trying to conditionally disable archiving
of largefiles.
I'm not sure if wrapfunction() is the right way to do this, but it seems to
work. The mysterious issue with lfstatus getting out of sync in the proxy and
the unfiltered view crops up again here. See the referenced cset for more info.
Bundle2 compression is more complex than the bundle1 one. Therefore it
is handled by the bundler itself. Moreover, on-disk bundle2 will
probably have a large number of flavors so simply adding a new "format"
for it does not seems the way to go.
This will be used in the next changeset to compress bundle2 strip backup.
The bundle10 format (plain changegroup-01) does not support general delta and
result into expensive delta re-computation when stripping. If the repository is
general delta, we store backups as bundle20 containing a changegroup-02 payload.
We remove the experimental feature related to strip backup bundle format because
this achieve the same goal in a leaner way. Removing the experimental option is
fine, that is why it experimental in the first place.
Compression of these bundles are coming in later changesets.
Because _phaserevs and _phasesets cache revision numbers, they must be
invalidated if there are new commits or stripped revisions. We could do
that by calling _phasecache.invalidate(), but it wasn't simple to be
integrated with the filecache mechanism.
So for now, phasecache will be recreated after repo.invalidate() if
00changelog.i was modified before.
This allows us to hide {branches} template keyword in a better way. Currently
it is achieved by copying keywords table and deleting 'branches' from it.
Future patches will require ui module to be passed to a help function, so
let's use it where appropriate.
Additional parens are necessary to silence a check-code warning.
Because _phaserevs and _phasesets cache revision numbers, they must be
invalidated if there are new commits or stripped revisions. We could do
that by calling _phasecache.invalidate(), but it wasn't simple to be
integrated with the filecache mechanism.
So for now, phasecache will be recreated after repo.invalidate() if
00changelog.i was modified before.
This avoids some visual flickering of the progress bar in convert and
probably some other operations. Previously, a line of output would
erase the progress bar, and then it would wait `progress.refresh`
seconds (default of 0.1) before redrawing the progress bar. Now if
we've ever painted a progress bar, we schedule the progress bar for
immediate repainting on the next progress call, which helps lend the
illusion that the progress bar is "always" there. In practice, it's
merely there more of the time, but it ends up being a lot easier to
read during convert.
This changeset adds support for a 'compression' parameter in bundle2 streams.
When set, it controls the compression algorithm used for the payload part of the
bundle2.
There is currently no usage of this except in tests.
The old lazy-copy code formed a chain of copied manifests with each
copy. Under typical operation, the stack never got more than a couple
of manifests deep and was fine. Under conditions like hgsubversion or
convert, the stack could get hundreds of manifests deep, and
eventually overflow the recursion limit for Python. I was able to
consistently reproduce this by converting an hgsubversion clone of
svn's history to treemanifests.
This may result in fewer manifests staying in memory during operations
like convert when treemanifests are in use, and should make those
operations faster since there will be significantly fewer noop
function calls going on.
A previous attempt (never mailed) of mine to fix this problem tried to
simply have all treemanifests only have a loadfunc - that caused
somewhat weird problems because the gettext() callable passed into
read() wasn't idempotent, so the easy solution is to have a loadfunc
and a copyfunc.
When looking up a base revision, we were ignoring the contents that were already
available in the manifest's _mancache. This patch allows us to use that data
instead of reading from the revlog.
This is useful in our pushrebase extension (which allows rebasing on the server
side during a push) because it allows us to prefetch the bundle base manifest
before aquiring the repo lock (1 second saving), which means doing less work inside the lock,
which means a 20% higher commit rate.
We are about to allow compressing the core of the bundle2. So we extract the
generation of this bits in its own parts to make this compression phases easier
in a later changesets.
As a comment in the code have been asking for, it is now possible to register
piece of code that handle parameters for the stream. I've been wondering is such
function should be class methods or not. I eventually went for externally
decorated methods to stick with the culture of extensibility from an extensions
that apply to bundle2.
The original name explicitly mention "Part", however it is also used outside of
parts related feature. We rename from 'UnsupportedPartError' to
'BundleUnknownFeatureError' to fix this.
For "space saving", bundle1 "strip" the first two bytes of the BZ stream since
they always are 'BZ'. So the current code boostrap the uncompressor with 'BZ'.
This hack is impractical in more generic case so we move it in a dedicated
"decompression".
This is adapted from 635285e0a942, that was added to paper for 3.5 release.
It adds another way to refer to branches, tags and bookmarks in urls: by name.
It's still possible to navigate to a specific changeset hash, but now you can
get more descriptive urls straight from /summary page, for example.
branchentry template (and so the whole branches table on /summary and
/branches) lost the column that had a plain changeset hash, because tags and
bookmarks don't have this column and also because there is already a way to
address branch by its changeset hash (changeset link just next to it). Maybe we
can instead bring this column with a plain changeset hash to tags and
bookmarks, but this, more terse, new look feels fine.
This is adapted from 635285e0a942, that was added to paper for 3.5 release.
It adds another way to refer to branches, tags and bookmarks in urls: by name.
It's still possible to navigate to a specific changeset hash, but now you can
get more descriptive urls straight from /summary page, for example.
branchentry template (and so the whole branches table on /summary and
/branches) lost the column that had a plain changeset hash, because tags and
bookmarks don't have this column and also because there is already a way to
address branch by its changeset hash (changeset link just next to it). Maybe we
can instead bring this column with a plain changeset hash to tags and
bookmarks, but this, more terse, new look feels fine.
This is part of a series that will allow locks to be inherited by subprocesses
in limited circumstances. This patch enables the logic introduced in previous
patches.
The earlier test worked only because the held count went up to 2, so the first
release brought it down to 1. Making a copy of the lock fixes that issue.
