If we copy a file followed by an update, it's possible for the parent
manifest to no longer contain the source file of the copy, which could cause
commit to fail. If this happens, we search backwares from the first
parent to find the most likely original revision.
optparse of python2.3 does not transform default values to the specified
type so e.g. "HGTEST_JOBS=4" (introduced in b8e8d6b0ae08) causes tests
to abort, because options.jobs is set to '4' instead of the number 4.
Example case:
Display file written in iso-8859-1 with current HGENCODING utf-8.
At the moment only an Error page appears because pygmentize
chokes on the replacement chars.
Alternatives:
1) Turn off highlighting and avoid UnicodeDecodeError
for files that are not in HGENCODING.
2) [this patch] use util.tolocal to display these files.
Alternative 2) seems ok, as this only concerns display and
readability.
See also: c5f1a58b8b9a, apparently put aside during refactor of
highlight.
Add test for UnicodeDecodeError with iso-8859-1 file contents.
- addresses will be properly encoded
- message bodies will also be encoded as we are not sending
patches that are meant to be applied
- update test output
- adapt test-keyword to ignore the new headers
'hg qrefresh --short file.txt' now adds changes made to file.txt to current
patch.
This builds on a patch for implementing --amend by Kirill Smelkov as discussed
in issue933.
FIXME: Why do mq refresh have two matchers if we only need one?
When the common part of a diff can be moved forward, move it forward.
Otherwise we don't get deterministic results (it would depends on the way we
split for the recursion).
That way we get identical hunks when doing the same change, it helps to solve
issue1295 (inconsistent diffs on different side during a merge).
Previously, an unknown node id would lead to the following error:
abort: 00changelog.i@343445453433: no node!
All other unknown revision would instead display as:
abort: unknown revision '343445453'!
The former error message has been suppressed in favor of the latter.
There is no technical reason to update it except it contains all the patches
already done in mercurial plus other stuff. It will be easier to update and
maintain in the future.
if after a and b has been applied, their hash starts with c, then the test
would fail (because there would be a rev c which would be seen as "applied")
so probability of failure would be 2*1/16.
Previously, fetch didn't really work when there were multiple named branches
in the repository. Now it tries to do the right thing(tm) in all situations.
For non-html mimetypes it doesn't make much sense. This also fixes the
issue that highlight unconditionally adds a <link/> tag for its CSS to
the template's header (which is pointless in text/plain output).
This is a new version of b6b16fec2a60 (which was backed out in faf83e1e40f5),
with an extra line removed to fix problems with hg serve. hg's internal web
server contains checking if the app isn't trying to write more bytes than
specified by the Content-Length header. The first try still contained an old
line that wrote the response, so the response was sent twice.
Besides updating the tests output, I had to push back at the end the test for
issue1193 in test-commit, solved by cset 31a0a36d6d95, because it was using the
current date for commit and was randomizing the subsequent hash.
Make merge and resolve trigger kwtemplater.restricted to compare
data without keyword expansion.
The keyword stays outside the conflict:
$Keyword$
<<<<<<< local
bar
=======
foo
>>>>>>> other
and will again be expanded on commit.
Demonstrate in test case.
This fixes problems mentioned in issue660 comments (unrelated to original
issue) where directory was renamed, and symlink was added instead.
In such situation addremove wasn't able to correctly detect that old files
no longer here, but tried to add symlink (and failed due collision with
old files).
Subversion allows revisions to be composed of subparts coming from revisions
before the parent or from other part of the repository. There is no simple
representation for these now, keep the changes but do not track their origins.
It is possible to specify that one of the internal merge tools (internal:fail,
internal:local or internal:other) should be used for performing merges on files
matching a given pattern. This test makes sure that such a setting actually
works.
The `svn commit` command does not detect changed files unless
their mtime has changed. A quick succession of, for instance,
`svn co ...; echo x >> y; svn ci` can thus lead to the change to y
being ignored.
Edited by pmezard to write in binary mode.
This patch adds two methods to revlog:
- ancestors: given a list of revisions returns their ancestors
- descendants: given a list of revisions return their descendants
This change ensures that removes happen first in applyupdates(). This avoids
issues where we try to make a case-only rename of a file on a case insensitive
system. Without this patch, the add of the new name happens before the remove
of the old one - which results in the file not existing, as the two names are
effectively the same.
With the patch, the old name gets removed then the new one gets added, which
is always safe.
Consistently enforces authorization checks set up in hgrc up front, so that
the actual commands don't have to worry about them and implementers of
hgweb alternatives can easily implement their own permission checks.
When we're using copies() to find changes between the working directory and
its first parent for diff/status/etc., use dirstate.copies() directly.
This avoids doing a full statwalk for simple diffs (issue1090) and
removes a special case from the status command.
Move the "Specifying Single Revisions" and "Specifying Multiple
Revisions" help topics from the manual page into the helptable
so they are available both online and in the manual page.
This patch allows a per-repository (for example, within a hgwebdir) selection
of pygments_style web option. No static .css files required.
Test edited by pmezard (compatibility fixes)
Backing out a changeset that is before a named branch branchpoint was
making the reverse changeset the tip of the old branch, which is wrong
and very confusing. So instead, we put it on the current named branch.
This fixes passing back fail messages mistaken for skip messages when
running with parallel jobs because run_children() only expects one message per
fail.
- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
/tmp is symlinked in MacOSX therefore test scripts as well as python modules
are installed in a symlinked location. coverage.py uses abspath() to normalize
its inputs which fails if these are referencing real paths. Use realpath()
instead.
- Added files are never deleted (only removed with --force).
- Modified files can only be removed with --force.
- With --after, only deleted files are removed.
- With --after --force, all files are removed but not deleted.
With this change, "hg clone" looks like this:
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
So the user sees
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
while Mercurial is writing to disk to populate the working directory
With this change, "hg clone" looks like this:
% hg clone big big-work
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
This should fix the race where
hg commit foo
<change foo without changing its size>
happens in the same second and status is fooled into thinking foo
is clean.
A configuration item is used to determine the timeout, since different
filesystems may have different requirements (I think VFAT needs 3s,
while most Unix filesystems are fine with 1s).
- Example: "hg tag -r 42 build-25 beta-1" will add tags build-25 and beta-1
for rev 42.
- The deprecated and undocumented usage "hg tag arg1 arg2" used to emit a
warning, then add tag arg1 for rev arg2 (equivalent to "hg tag -r arg2 arg1").
It will now add tags arg1 and arg2 for the current revision.
- If one tag triggers an error, no tags are added/removed (all or nothing).
If we don't change any rwx bit in the last test, hg will skip the
calls to chmod since it'll assume they're not needed.
This might fix things on BSD systems.
This can make a difference when there are filters involved and
decode(encode(working-dir-data)) != working-dir-data
even though
encode(decode(repo-data)) == repo-data
An example is a working dir file that uses only \n when you're using
the win32text extension.
We encode the previous state as a negative file size (AFAICS, previous
versions of hg always have size == 0 when state == 'r').
We save the state of 'm'erged and dirty files, because they're the
two states that indicate that a file has to be committed on a merge
to correctly record per-file history.
The self patching of files when diffed with a backup is a bit peculiar to me.
It makes sense in mpatch, that's less clear in mercurial patching code. Let's
document and preserve it for now.
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.
