Before this patch, "hg summary --large" shows how many largefiles are
changed or added in outgoing revisions only in the point of the view
of filenames.
For example, according to the number of outgoing largefiles shown in
"hg summary" output, users should expect that the former below costs
much more to upload outgoing largefiles than the latter.
- outgoing revisions add a hundred largefiles, but all of them refer
the same data entity
in this case, only one data entity is outgoing, even though "hg
summary" says that a hundred largefiles are outgoing.
- a hundred outgoing revisions change only one largefile with
distinct data
in this case, a hundred data entities are outgoing, even though
"hg summary" says that only one largefile is outgoing.
But the latter costs much more than the former, in fact.
This patch shows also how many data entities are outgoing at "hg
summary" by counting number of unique hash values for outgoing
largefiles.
This patch introduces "_getoutgoings" to centralize the logic
(de-duplication, too) into it for convenience of subsequent patches,
even though it is not required in "hg summary" case.
Before this patch, all operations applied on ".gitmodules" at git
source revisions are treated as modification, even if they are
actually removal of it.
If removal of ".gitmodules" is treated as modification unexpectedly,
"hg convert" is aborted by the exception raised in
"retrievegitmodules()" for ".gitmodules" at the git source revision
removing it, because that revision doesn't have any information of
".gitmodules".
This patch detects removal of ".gitmodules" at git source revisions
correctly.
If ".gitmodules" is removed at the git source revision, this patch
records "hex(nullid)" as the contents hash value for ".hgsub" and
".hgsubstate" at the destination revision.
This patch makes "getfile()" raise IOError also for ".hgstatus" and
".hgsubstate" if the contents hash value is "hex(nullid)", and this
tells removal of ".hgstatus" and ".hgsubstate" at the destination
revision to "localrepository.commitctx()" correctly.
For files other than ".hgstatus" and ".hgsubstate", checking the
contents hash value in "getfile()" may be redundant, because
"catfile()" for them also does so.
But this patch chooses writing it only once at the beginning of
"getfile()", to avoid writing same code twice both for ".hgsub" and
".hgsubstate" separately.
Before this patch, 'progress' extension applies 'len' on byte sequence
to get column width of it, but it causes incorrect result, when length
of byte sequence and columns in display are different from each other
in multi-byte characters.
This patch uses 'encoding.colwidth' to get column width of items in
output line correctly, even if it contains multi-byte characters.
Before this patch, 'progress' extension trims items in output line by
directly slicing byte sequence, but it may split at intermediate
multi-byte sequence.
This patch uses 'encoding.trim' to trim items in output line
correctly, even if it contains multi-byte characters.
Before this patch, 'progress' extension applies 'len' on byte sequence
to get column width of it, but it causes incorrect result, when length
of byte sequence and columns in display are different from each other
in multi-byte characters.
This patch uses 'encoding.colwidth' to get column width of output line
correctly, even if it contains multi-byte characters.
Before this patch, 'progress' extension trims output line by directly
slicing byte sequence, but it may split at intermediate multi-byte
sequence.
This patch uses 'encoding.trim' to trim output line correctly, even if
it contains multi-byte characters.
"rm -f loop.pyc" before changing "loop.py" in "test-progress.t"
ensures that re-compilation of "loop.py", even if "loop.py" and
"loop.pyc" have same timestamp in seconds.
Before this patch, trimming description of each changesets in histedit
may split at intermediate multi-byte sequence.
This patch uses 'util.ellipsis' to trim description of each changesets
instead of directly slicing byte sequence.
Even though 'util.ellipsis' adds '...' as ellipsis when specified
string is trimmed (= this changes result of trimming), this patch uses
it, because:
- it can be used without any additional 'import', and
- ellipsis seems to be better than just trimming, for usability
This option had very limited utility and counterintuitive behavior and
collided unfortunately with the much later -B option.
Normally we would no-op such a feature so as to avoid annoying existing
scripts. However, we have to weigh that against the silent misbehavior
that results when users mistakenly intended to use -B: because -b
takes no arg, the bookmark gets interpreted as a normal revision, and
gets stripped without removing the associated bookmark, while also not
backing up the revision in question. A no-op behavior or warning would only
remove the latter half of the misadventure.
The only users I can find of this feature were using it in error and
have since stopped. The few (if any) remaining users of this feature
would be better served by --no-backup.
In the context of standalone Hg receiving a set of incoming changes, it makes
sense for the Bugzilla module to cache basic setup to avoid reconnecting
to Bugzilla for each change. After processing the changes, Hg will exit
and so the connection is short-lived.
But this doesn't work too well when used from a long-lived environment
such as hgweb or Kallithea where, for example, the connection can time out.
So take the simple approach, abandon the cache and do the basic setup on
each call. This fixes current problems with Kallithea.
The defect was that copies were always duplicated against the target
revision, rather than the first parent of the revision being
rebased. This produced nominally correct results if changes were
rebased one at a time (or with --collapse), but was wrong if we
rebased a sequence of changesets which contained a sequence of copies.
Before this patch, 'hg fetch' may cause unexpected conflict, if 'hg
fetch'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg fetch' for internal
merge by adding 'fetch' to 'restricted' command list like 'merge'.
This patch uses 'hg import' to safely create the new head to be merged
at succeeding 'hg fetch', because:
- branch of revision #10 is different from one of #11 in 'Test'
repository, so just 'hg fetch -r 11' doesn't cause merging between
them
this means the new head should be created manually.
- 'hg import' is easier and safer than 'cat <<EOF' and 'hg commit'
to replay same changes including special characters like '$'
safeness of 'hg import' with keyword extension is already examined
in 'test-keyword.t'.
Before this patch, 'hg histedit' may cause unexpected conflict, if 'hg
histedit'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg histedit' for
internal merge by adding 'histedit' to 'restricted' command list like
'merge'.
Test in this patch just swaps order of revision #13 and #14: this is
enough to cause internal merge.
Before this patch, 'hg backout' may cause unexpected conflict, if 'hg
backout'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg backout' for
internal merge by adding 'backout' to 'restricted' command list like
'merge'.
Before this patch, 'hg graft' may cause unexpected conflict, if 'hg
graft'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg graft' for internal
merge by adding 'graft' to 'restricted' command list like 'merge'.
Before this patch, 'hg rebase' may cause unexpected conflict, if 'hg
rebase'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg rebase' for internal
merge by adding 'rebase' to 'restricted' command list like 'merge'.
This patch specifies '--keep' to 'hg rebase', because revision #10 is
useful also for tests in succeeding patches.
Before this patch, 'hg unshelve' may cause unexpected conflict, if 'hg
unshelve'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg unshelve' for
internal merge by adding 'unshelve' to 'restricted' command list like
'merge'.
Bugzilla 4.4.3 and later remove the old cookie based session authentication
from the Web Services API and replace it with a login token. The session
can now also be restricted to the originating IP.
Add the necessary to the extension so it works with 4.4.3 and later.
The error only occured when Python didn't have curses - such as on Windows and
when Python was built without curses support.
No curses can also be emulated by (re)moving .../lib/python2.7/curses/ from the
Python installation.
It is left as an exercise to figure out exactly what changed in Mercurial that
triggered this error.
When invoked from another directory, the matchers m._cwd will be the absolute
path. The code for calculating relative path to .hglf did not consider that and
log would fail with weird errors and paths.
For now, just don't do any largefile magic when invoked from other directories.
The documentation says we exit 1 if we have nothing to do, so avoid
breaking that contract when we're passed an empty revset.
This was changed in http://www.selenic.com/hg/rev/1d4f2abc281b to
improve the error message; keep the improved message, just not the
abort.
Most UTF-8 aware terminals convert multibyte sequences into a single displayed
characters. Because the first column is padded by counting bytes, the second
column is not perfectly aligned in the presence of non ASCII characters.
Before this patch, the name of a newly added option had to be added
into each string that was passed to the "checkopt()" internal
function: these are white-space-separated list of un-acceptable option
names (= "black list" for the specified "opt").
This new option had to be added into multiple strings because each
option could belong to only one action of "create", "cleanup",
"delete" or "list".
In addition to this redundancy, each string passed to "checkopt()" was
already too long to include a new one.
This patch refactors option combination check to make it easier to add
a new option in a subsequent patch.
New "checkopt()" only takes one action ("cleanup", "delete" or
"list"), and checks whether all explicitly activated options are
allowed for it or not (if specified action is activated in "opts").
The "date" entry is listed in "allowables", but commented out,
because:
- "date" shouldn't be checked for test
checking "date" causes unexpected failure of "test-shelve.t",
because "run-test.py" puts "[default] shelve = --date '0 0'" into
hgrc.
- explicitly listing it can advertise that ignoring it is intentional
This patch doesn't choose "white list" for the specified "opt", to
avoid treating global options.
In case we have revs to strip, delete the bookmark after the strip succeeds, not
beforehand as we might still abort due to dirty working directory, etc.
Log for largefiles was failing for graph log since it was overriding match
instead of matchandpats.
[Mads Kiilerich modified this patch to address his review comments and ended up
rewriting/removing most of it.]
Commit 9bcdffd81aaf changed how newfiles get passed to commitfunc, but
did not change the corresponding comment that explains this. This
commit also updates this comment.
