The existing code seemed to have incorrect assumptions about how parameter
lists are represented by the parser.
Now the match and replace functions have been merged and simplified by using
getlist().
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
$ hg revert
abort: no files or directories specified
(uncommitted merge, use --all to discard all changes, or 'hg update -C .' to abort the merge)
This is a guaranteed by the protocol: clients know they need to read one chunk
off of the 'o' channel and treat that as the hello message.
They should ignore fields they don't recognize so they stay compatible with
new versions of the server in case we decide to add something.
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
AFTER:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
Closing here means we've closed the repo passed to us in the request,
which is not our responsibility.
This is essential for bundlerepo, and possibly other localrepository
subclasses who do something in their close().
output on stderr will also be written to ui.fout, unless sys.__stdout__
is passed in (see util.system), thus not changing previous behavior.
This fixes a bug where hooks run through the command server would mess up
with the command protocol, sending non-channeled data to the client.
No real reason for a client to do this, but still possible.
Previously if the client sent no arguments, a list with an empty string ['']
would be used as the arguments to dispatch, which would cause hg to complain
about an ambiguous command.
Instead, we simply check for no arguments and use an empty list instead (which
is equivalent to invoking hg with no args on the command line).
Old discovery only returned incoming heads, not all of them (for
changegroupsubset). New discovery must always return all of the remote heads
(for getbundle). I failed to properly adjust treediscovery in 43f4c1113c8d
when introducing setdiscovery.
The actual observable problem was 'remote: unsynced changes' when trying
to push a cset on one named branch to a server with a new cset on another
named branch. This scenario is now tested in test-treediscovery.t.
- the power of 2 ones should be kiB, MiB, etc.
- the power of 10 ones (SI standard) should be kB, MB, but we're currently
using the industry traditional units elsewhere
We only call status if needed to avoid walking the working directory
or comparing manifests.
Similarly, we scan for whether unknown or ignored files are mentioned
so we can include them.
This forcibly walks the tree looking for unknown and ignored files,
which is suboptimal. A better approach would scan the tree first to
find required status components and skip the status check entirely if
it's unused.
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
Any entries in subjectAltName would prevent fallback to using commonName, but
RFC 2818 says:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.
We now only consider dNSNames in subjectAltName.
(dNSName is known as 'DNS' in OpenSSL/Python.)
We do this by ensuring the working copy is clean and then blowing away
the working copy and replacing it with one from the desired path. We
could probably use 'svn switch' to do this more efficiently, but
there's some subtle logic required to get that right and this is
more likely to work reliably.
merge.update() was missing a few dirtiness checks from workingcontext,
including subrepo cleanliness checks. Using wc.dirty() instead of
one-off checks for various forms of dirtiness will be significantly
safer.
Like keyword(), but does not search in filenames and users.
No grepdesc() or descgrep() added, because it might be bad to introduce
grepfoo() versions of too many string searches.
This attributes hold the set of all revisions that should be ommited by command
and tools displaying changesets.
This set is given as a hit. Command and tools are responsible to check it in
order to filter they outpur.
Code adding revisions to the set are responsible to the consistency of it's
data.
If the ui I/O descriptors aren't real descriptors, they cannot be duped.
Instead, we return a wrapper object that behaves the same, and
can be closed (by overriding close and doing nothing).
Though both give the same result (a NUL byte), I found that I tend to
read "\000" as "\0" + "00", which is something completely different.
I did not change the occurance of "\000" in archival.py since there
are other octal constants in that file.
This means that we now discover both subset conditions (local<remote and
remote<local) in a single roundtrip without ever constructing an actual
sample (which takes a bit of client CPU).
Makes lookup, heads, known, branchmap, pushkey, and listkeys batchable.
It could, for instance, be interesting to use this to batch calls to
lookup when a pull or clone has multiple --rev arguments. The next patch
is going to batch heads and known to slightly tune discovery.
Two imports were omitted in the restructure of the code creating
sslutil.py, socket and httplib are required when the 'ssl' module
cannot be imported, restoring these imports allows mercurial to run
on python2.4+2.5.
This feature is more a way to test patching without a working directory than
something people asked about. Adding a --rev option to specify the parent patch
revision would make it a little more useful.
What this change introduces is patch.repobackend class which let patches be
applied against repository revisions. The caller must supply a filestore object
to receive patched content, which can be turned into a memctx with
patch.makememctx() helper.
The plus and minus characters are normally not the same width in a
non-monospace font, and this made the line length change when the
diffstat display was toggled.
The square brackets are not rendered in a monospace font to ensure
that they align with the parenthesis on the same line.
There is now only peer scheme lookup. Repository lookup goes through
peer scheme lookup. When peer and repo types are finally separated,
repo lookup will use peer.local() to get a repository object.
The underbar is dropped so that extensions can patch the table.
before:
$ hg forget foo
foo: No such file or directory
not removing foo: file is already untracked
after:
$ hg forget foo
foo: No such file or directory
Displayed in a row of the changeset summary table, underneath the list of
files. When the page is loaded, only the diff summary is displayed. The full
diffstat is only displayed when the [+] link is selected.
This is the same message displayed at the end of the "diff --stat" command.
For example, "9 files changed, 1651 insertions(+), 2 deletions(-)".
The webutil.diffstatgen function allows the diffstat data to be lazily
calculated only once and then re-used.
- Add patchmeta.copy() and emit copies from iterhunks. Modifying patchmeta
instances in applydiff() makes things simpler.
- Rename selectfile() into makepatchmeta(). It is responsible for creating
patchmeta for regular patches.
- Pass patchmeta objects to patchfile() directly
patchmeta instances were associated with git patches, for regular patches we
had to pass additional variables to tell the patch intent to patchfile().
Instead, we generate patchmeta for regular patches and pass them. This will
also help with patch filtering by matcher objects.
This information is more correctly returned by backends.
The extra updated file removed from test-mq-merge.t output came from changes
from git patches being counted before being really applied in some cases.
The templates output the filename, the total number of changes to the file
and a bar graph of the adds and removes. The filename is a link into the diff
output.
The diffstat is not yet displayed, but it can be manually added to the
changeset page template.
This allows the diffstat templates to link into the diff output. For example,
the URLs of the first three files within the diff are #l1.1, #l2.1, #l3.1.
The webutil.diffstat function now returns a diffstat template for each file
in the diff. It previously returned a template for each file returned by
ctx.files() which did not work well for merge changesets.
The current bookmark is stored in bookmark.current, supposingly in UTF-8.
But the call to encoding.fromlocal() is missing, therefore Hg is not able
to recognize the current bookmark in the case that bookmark uses
characters of which the bit stream is different between local encoding
and UTF-8.
For example, the Chinese version of Windows cmd uses gbk(cp936), not UTF-8.
Therefore I won't be able to make a Chinese bookmark current.
By wrapping mark in a encoding.fromlocal() call, the problem is solved.
This reduces documentation confusion between the need to:
a) hg revert -a -r . (drop all changes from a merge)
b) hg up -C . (drop the second parent entirely)
Currently revert is one of two commands (the other being tag) that
still complains about uncommitted merges, dating from its former use
of a generic defaultrev function that aborted.
New users have a tendency to mistake 'revert' as the command to use to
check out old revisions. They also occasionally mistake revert for a
generalized undo (compare rollback).
This version intentionally aims to avoid mentioning 'earlier' and thus
intentionally no longer alludes to the (secondary) -r behavior (which
in fact is not actually limited to 'earlier').
Instead, we mention checkout state, to convey that we can
restore things to the way they were when checked out.
Synchronizing on bfile does not work on file removal where bfile is /dev/null.
We match items on afile or bfile instead. The incorrect code makes iterhunks()
to emit patchmeta and hunks separately in some cases. This is currently hidden
by applydiff() being too tolerant when processing patchmeta, and will be fixed
later.
previously, this info was only shown with --debug
Note that the new remote heads are only shown if the command aborts,
that is, they are *not* shown if --force was specified.
See also change 914ebeb62db8.
and don't mention the branch if it's the default branch.
OLD:
$ hg push ../a
pushing to ../a
searching for changes
abort: push creates new remote heads on branch 'default'!
(you should pull and merge or use push -f to force)
NEW:
$ hg push ../a
pushing to ../a
searching for changes
abort: push creates new remote head 1e108cc5548c!
(you should pull and merge or use push -f to force)
This helps to identify which local head is causing troubles.
See also change 914ebeb62db8.
Inlining it into it's last remaining call place in cmdutil.copy.
Note that cmdutil.copy is called with the wlock already held, so no additional
locking is needed to call util.unlinkpath.
We do not need to wrap the util.unlinkpath call into a try block, because
at that point we already know whether abssrc exists or not -- thanks to the
preceding util.copyfile call. Adding a new local 'srcexists' in cmdutil.copy
for that purpose.
Remove the lambda used to wrap webutil.diffstat because:
- functions passed to the templater must accept keyword arguments
- webutil.diffstat is a generator, so already calculates the diffstat lazily
This reverts the changes made to a4067e29e29d after it was submitted to the
mailing list but before it was queued.
This includes all affected files, so it can be used for an extended view of
the files or as a replacement for the filenodelink and filenolink templates.
Previously, pull would not update if new branch heads were received,
whereas pull && update would move to the tipmost branch head.
Also change the "crosses branches" abort in merge.update from
"crosses branches (merge branches or use --check to force update)"
to
"crosses branches (merge branches or update --check to force update)"
since it can no longer assume the user is running hg update.
Without the blank line, the minirst parser renders
Term-1
Line-1
Line-2
Term-2
Line-1
as
Term-1
Line-1
Line-2 Term-2 Line-1
because the second term is seen as a paragraph.
git patches may require copies to be handled out-of-order. For instance, take
the following sequence:
* modify a
* copy a into b
Here, we have to generate b from a before its modification. To do so,
applydiff() was scanning for copy metadata and performing the copies before
processing the other changes in-order. While smart and efficient, this approach
complicates things by handling file copies and file creations at different
places and times. While a new file must not exist before being patched a copied
file already exists before applying the first hunk.
Instead of copying the files at their final destination before patching, we
store them in a temporary file location and retrieve them when patching. The
filestore always stores file content in real files but nothing prevents adding
a cache layer. The filestore class was kept separate from fsbackend for at
least two reasons:
- This class is likely to be reused as a temporary result store for a future
repository patching call (entries just have to be extended to contain copy
sources).
- Delegating this role to backends might be more efficient in a repository
backend case: the source files are already available in the repository itself
and do not need to be copied again. It also means that third-parties backend
would have to implement two other methods. If we ever decide to merge the
filestore feature into backend, a minimalistic approach would be to compose
with filestore directly. Keep in mind this copy overhead only applies for
copy/rename sources, and may even be reduced to copy sources which have to
handled ahead of time.
The patcher has to know if a file is being created or removed to check if the
target already exists, or to actually unlink the file when a hunk emptying it
is applied. This was done by embedding the creation/removal information in the
first (and only) hunk attached to the file.
There are two problems with this approach:
- creation/removal is really a property of the file being patched and not its
hunk.
- for regular patches, file creation cannot be deduced at parsing time: there
are case where the *stripped* file paths must be compared. Modifying hunks
after their creation is clumsy and prevent further refactorings related to
copies handling.
Instead, we delegate this job to selectfile() which has all the relevant
information, and remove the hunk createfile() and rmfile() methods.
workingctx.remove(list, unlink=True) is unsuited here, because it does too
much: it also unlinks added files. But the command 'hg remove' is specified
to *never* unlink added files.
Instead, we now unlink the files at the commands.remove level (if --after was
not specified) and use workingctx.forget for all files.
As an added bonus, this happens to eliminate a wlock acquire/release pair,
since the previous implementation caused
acquire wlock
release wlock
acquire wlock
release wlock
where the first pair of acquire/release was caused by the workingctx.forget
call, and the second by the workingctx.remove call.
Currently, if there is a bare git subrepo, but it is at the "right"
revision, calling dirty() will error because diff-index does not work
on bare repos. This patch makes it so bare subrepos are always
considered dirty.
and check if we got one before creating.
note that the contents of the ui object might change after
dispatch() returns (by options passed through --config for example),
to ensure it doesn't, pass a copy() of it.
Restore the previous diffstat behaviour of scaling by the maximum number of
changes to a single file. Changeset 7bb0e22a7988 modified the diffstat to be
scaled by the total number of changes. This seems to have been unintentional.
Firstly, I think we should do this for all new wire commands, just
to be on the safe side. So I want to get this into the 1.9 release.
Secondly, there actually is potential here that sometimes the server
can know that the number of its nodes which can possibly still be
undecided on the client is small. It might then just send them along
directly (cutting short the end game). This, however, requires
walking the graph on the server, which can be expensive, so for the
moment we're not actually doing it.
It has substantially different semantics from forget at the command
layer, so change it to avoid confusion.
We can't simply combine it with remove because we need to explicitly
drop non-added files in some cases like commit.
This new Python code should be equivalent in behavior to the if
statement at line 312 of parsers.c. Without this, the pure-python
parsers improperly ignore truncated revlogs as created in
test-verify.t.
Changeset 20b319765bcf introduced the unbundlehash capability and
unconditionally hashed the heads on the client side. By mistake, the
heads were also cased in the heads == ['force'] case.
extensions that depend on other extensions (such as record) use this pattern
to check if the dependant extension is available:
try:
mq = extensions.find('mq')
except KeyError:
return
but since if an error occurs while loading an extension it leaves its entry
in the _extensions map as None, we want to raise in that situation too.
(rather than adding another check if the return value is None)
Failing to do so makes it impossible to use the memctx API to create a
changeset with a commit message or username outside of the current
encoding.encoding setting.
