The only non-obvious part is the use of sys.{__stderr__,__stdout__},
which is needed because sshserver overrides sys.stdout.
This makes a test that I added back in revision d71c96fd819f ineffective.
The error message at startup when the address/port could not be bound
was confusing:
hg serve
abort: cannot start server: Address already in use
Be more explicit:
$ hg serve -a localhost
abort: cannot start server at 'localhost:8000': Address already in use
Also be more explicit on success, showing hostname and ip address/port:
$ hg -v serve -a localhost -p 80
listening at http://localhost/ (127.0.0.1:80)
We are careful to handle a missconfigured machine whose hostname does not
resolve, falling back to the address given at the command line.
Remove a dead-code error message.
This normalization consists of:
- stripping trailing whitespace
- always using "\n" as the line separator
I think the main reason rawcommit was skipping this normalization was
an attempt to preserve hashes during an hg->hg conversion.
While this is a nice goal, it's not particularly interesting in
practice. Since SHA-1 is so strong, the only safe way to do it is to
have absolutely identical revisions. But:
- if the original revision was created with a recent version of hg,
the commit message will be the same, with or without that
normalization
- if it was created with an ancient version of hg that didn't do any
normalization, even if the commit message is identical, the file list
in the changelog is likely to be different (e.g. no removed files),
and there were some old issues with e.g. extra file merging, which
will end up changing the hash anyway
- in any case, if one *really* has to preserve hashes, it's easier
(and faster) to fake a partial conversion using something like:
hg clone -U -r rev orig-repo new-repo
hg -R new-repo log --template '#node# #node#\n' > new-repo/.hg/shamap
Additionally, we've had some reports of problems arising from this lack
of normalization - e.g. issue871, and a user that was wondering why
hg export/hg import was not preserving hashes when there was nothing
unusual going on (it was just import doing the normalization that had
been skipped).
This also means that it's even more unlikely to get identical revisions
when going $VCS->hg->$VCS.
This treats newly pulled changes as authoritative, and local changes as
the "satellite" changes.
The prior default behaviour is still available, via the --switch-parent
option.
The '-q' flag was ignored in status command. But this flag
can be used to hide non-tracked files in hg status output.
This small correction makes status command more general,
similar to 'svn status', where '-q' flag has the same effect.
The '-u' and '-A' flags have priority over '-q'.
A testcase and doc-string for status was extended to cover
'-q' flag.
Like some renames or copy operations, binary file removal does not generate any
"file" or "hunk" action, but was not tagged as such and let iterhunk() assume
no hunk was applied for the deleted file.
manifest.tmpl is still used, so people having their own templates don't have
to change them. "cmd=manifest" still works, new style URLs are not affected,
because they already used "/file/".
Useful for creating XML documents directly from Hg logging. Can also be used for
HTML. For use in content, will escape '&', '<', and for completeness '>'
(although it is not strictly necessary). For use in attributes, will also escape
' and ". Will also replace nonprinting (ASCII) control characters with spaces,
since these are illegal in XML.
- eluding convert.svn.branches defaults to "branches"
- convert.svn.branches= disables branches detection
- convert.svn.branches=/ is equivalent to former convert.svn.branches=
Currently, backout is creating a backout revision as a child node of the
backed out node and will leave you at this new head. This has several
drawbacks:
* this changes the current head
* when there is a long history between the backed out node and the
current head, this will generate a huge number of diffs that are scary
at first sight, and not very natural to review before commit.
The change consists to switch back to the original node as soon as the
backout node (which becomes the new tip) has been created. Then the
--merge option can just merge this new tip in the current node.
* the current head/node is not changed from the user's point of view
* even without using the --merge option, the backout revision is still
easy to locate, as this is the tip
* the merge is much more intuitive as diffs of the merge is right you
are looking to backout
We might be able to do something smarter about this in dirstate.status
for files in normallookup state, but that would require some extra
care to keep backwards compatibility.
These two commands care about the list of modified files returned
by repo.status and we may need to do a full content comparison to
populate that list.
test-glog uses debugsetparents instead of update+merge to create
some funky DAGs, and so the dirstate contents won't be consistent
with the checked out revision.
Passing an explicit list of files to commit reduces a bit the
dependency on the dirstate.
Using a non-deprecated rawcommit might be better here.
In particular: if invoked without -R from a CWD not inside a repo, having been
passed one or more file paths as command arguments, where the nearest enclosing
repo of all of those paths is the same, quietly infer a -R option for that repo.
Otherwise abort with an error message as before.
commit (aborts _after_ typing in a commit message)
backout (aborted after the initial revert)
tag (edited .hgtags and couldn't commit)
import (patch applied, then commit fails)
qnew (aborts on bad dates, but writes any valid date into the # Date header)
qrefresh (like qnew)
sign (like tag)
fetch (merge, merge, merge, merge, abort)
Two branches a and b starting at root, with commits interleaved like:
root a0 a1 b0 a2 a3 b1
were converted in the following order:
root a0 b0 a1 b1 a2 a3
Replace depth based toposort with a more classic traversal method.
This doesn't make a difference right now, but after the next revision
some files in state 'a' may end up in the deleted list, and revert
won't be able to just remove all files in that list.
commands.revert calculates everything that has to be done and then
calls hg.revert to checkout and remove files. Unfortunately,
hg.revert has to recalculate everything and that can take a long
while, since it always operates on the whole working dir.
Changing commands.revert to manually checkout and remove files
makes things considerably faster, especially if we're reverting
a single file in a repo with a huge number of files.
This should be enough to close issue857.
With a pattern like '^directory$' in .hgignore, a "hg status directory"
would still walk "directory" and all its subdirs.
This is the first half of a fix for issue886.
That's just an artifact of the current implementation, and I'll change
that soon.
Bonus points:
- we don't care about the unknown list at all
- we don't print an extra message if we try to revert a removed file
that is not present in the target revision
This should avoid a bad performance problem when the branch cache is
not up-to-date, and hgweb can't write an updated version because it
lacks permissions.
The current list of reserved names includes only mq control files.
Also, reserve names starting with ".hg" (to avoid troubles with
e.g. .hgignore and .hgtags), and with ".mq" (to allow future
extensions).
This should fix issue841.
We already disallow committing on top of an mq revision exactly
to avoid losing this new revision during a qpop/qrefresh, so this
can be seen as an additional safety check.
If this is not enough to fix issue844, it should at least prevent
it from happening.
Previously the parent was determined by the last changeset where the branched
file was changed even if the branch is based on an earlier revision.
Fix written by mpm.
Reported and explained by Peter Arrenbrecht <peter.arrenbrecht@gmail.com>.
Following file additions were skipped but empty files were still created. This situation could lead to qrefresh losing patch information.
If paths are supplied but resolve to nothing, localrepo.commit() is called with an empty set and commits the whole dirstate. Avoid this by passing the match function to commit.
Part of test-tags was modified just to be sure this works.
The change in test-archive-symlinks is necessary to avoid a "helpful"
warning from GNU tar ("implausibly old time stamp 1970-01-01 00:00:00").
Relying on the exact return of statwalk would cause us to abort
when there was at least one tracked file inside an ignored directory.
This patch forces an extra walk of the whole working directory even
on sane filesystems, where it wouldn't be needed.
Fixes issue621.
Workaround for dir-changed-to-file updates mentioned
in rev c3f3393b9096 doesn't actually work since tests
introduced in mentioned changeset prevented dirstate
updates even if working directory updates succeded.
Make tests more relaxed for dirstate operations
not directly accessible from cli. See also issue660.
While here, move _dirs existance check from _decpath()
to _changepath() for unification.
Allow adding to dirstate files that clash with previously existing
but marked for removal. Protect from reintroducing clashes by revert.
This change doesn't address related issues with update. Current
workaround is to do "clean" update by manually removing conflicting
files/dirs from working directory.
if not verbose:
- print 's' rather than '.'
- pass skipped test reports back to parent for -j
- report which tests were skipped at the end
- print '.' after test completion
- hg archive --no-decode has no short option, too, and maybe both could use
-d in the future to select revisions by date.
- opts.get makes python scripts calling cat() happy, because they don't have
to pass the new option.
The new registration of in-process data filters (introduced in
75177cef51d3 & 8c9fa240ac96) failed to correctly strip the filter name
from its arguments before passing the "command" to the filter
function. Thus a registration such as
[decode]
*.gz = compress: -9
would result in the associated filter function being called with the
argument 'compress: -9' rather than just '-9' as expected.
prevent issues due to global [keyword] filename patterns:
- add email to nokwcommands
- protect everything under .hg from expansion
(tested with qcommit)
- exclude everything starting with .hg* just in case
prevent abort when pulling from bundlerepo:
- do not set up kwrepo for bundlerepo
expansion inside a bundle is nonsense
bundlerepo issue spotted and test case provided by pmezard.
Add [merge-tool] hgrc section with:
<tool>.executable = name or path (<tool>)
<tool>.args = args with $local/base/other/output ($local $base $other)
<tool>.priority = priority (default 0)
<tool>.binary = handles binary (False)
<tool>.symlink = handles symlinks (False)
<tool>.checkconflict = check for conflict markers (False)
<tool>.premerge = try internal simplemerge (True if not binary or symlink)
Four built-in tools: internal:{merge,local,other,fail}
Add [merge-patterns] section of the form:
<pattern> = <tool>
Priority of settings is:
HGMERGE
merge-patterns
ui:merge
merge-tools by priority
hgmerge, if it can be found
Changes:
unsuccessful merges leave .orig files
While some can function with just some text and an optional command name,
others may want a repository object, a ui object, and a file path.
Use the enhanced information to good effect in win32text.dumbdecode's warning.
The prose section of the help text for the command already said that -u and -m
are accepted, but -u was not listed in the table of options, and did not work.
Useful when accepting patches from other people made by hg diff rather than hg
export. For completeness, also accepting -d DATE.
[CHANGES: rebased against 2f0da487820f, --no-commit option.]
This removes the ability for templates to add custom HTTP headers, which can
easily be re-added if someone needs it. Thanks to asak for repeatedly reviewing
this patch and helping to iron out the quirks.
When we remove revision N from the repository, all revisions >= N are
affected: either it's a descendant from N and will also be removed, or
it's not a descendant of N and will be renumbered.
As a consequence, we have to (at least temporarily) remove all filelog
and manifest revisions that have a linkrev >= N, readding some of them
later.
Unfortunately, it's possible to have a revlog with two revisions
r1 and r2 such that r1 < r2, but linkrev(r1) > linkrev(r2). If we try
to strip revision linkrev(r1) from the repository, we'll also lose
revision r2 when we truncate this revlog.
We already use changegroupsubset to create a temporary changegroup
containing the revisions that have to be restored, but that function is
unable to detect that we also wanted to save the r2 in the case above.
So we manually calculate these extra nodes and pass it to changegroupsubset.
This should fix issue764.
mq:
Ensure that expanded keywords do not make it into patches.
- disable expansion when reading filelog
- shrink expanded keywords when reading from working dir (wread)
(q)record:
Avoid additional hunks due to expanded keywords. However this is
still a compromise, as keyword expansions are not updated in
working directory because record should not overwrite files.
Mention above shortcomings and "hg kwexpand" workaround in help
and update test output.
system argument parsing:
Command detection might be slightly more expensive with
dispatch._parse, but we will need this for improving "hg diff"
output.
We'd mistakenly made the -p option always on, which meant there was no
way to turn it off. It also meant that we were sometimes splitting
multibyte characters in function name, which isn't a good default.
In some subversion repositories, trunk is present but no branches
are used. The current code is assuming that both trunk and branches
must exist before adding trunk's head to the heads list.
It's just better to separate the branch layout stuff from the trunk one.
