This change is brain damaged, there is no reason the copyfrom revision of the
project items may have any relevance when deciding the revision parent. It is
meaningful only when fetching files content.
Incorrect converted graph was spotted in pyglet svn repository at:
------------------------------------------------------------------------
r274 | r1chardj0n3s | 2006-12-21 02:02:14 +0100 (Jeu, 21 Dec 2006) | 2 lines
Changed paths:
A /branches/richard-glx-version (from /trunk:269)
M /branches/richard-glx-version/pyglet/window/xlib/__init__.py
R /branches/richard-glx-version/tests/test.py (from /trunk/tests/test.py:270)
R /branches/richard-glx-version/tools/info.py (from /trunk/tools/info.py:272)
R /branches/richard-glx-version/website/get_involved.php (from /trunk/website/get_involved.php:273)
Branching to horribly mangle GLX
On AIX /etc/profile sets LOGNAME read only. This causes test-acl to
fail when it comes to set LOGNAME in do_push().
Work around this by using env to set LOGNAME and run the command.
This feature somehow duplicates [collections] but it is simpler to use and has
less issues under Windows where using absolute path as configuration file key
is not supported.
Suggested by Dirkjan Ochtman <dirkjan@ochtman.nl>
For different reasons these tests will fail if run in a tmpdir which is in a hg
repo.
The following three tests assumes no .hg in path dirs - I don't know how to
work around that:
* test-dispatch explicitly tests for no repo and expects "abort: There is no
Mercurial repository here (.hg not found)!"
* test-extension expects parentui to be None when not cd'ed to a repo dir
* test-globalopts tests that implicit -R works correctly - that could perhaps be
done from another repo instead of assuming no repo
The following two might be worth investigating further:
* test-convert-svn-sink fails for unknown reasons, starting with "abort:
unresolved merge conflicts (see hg resolve)"
* test-glog gets strange failures when testing "from outer space"
hgweb tests often failed on my system because the serve port wasn't free when a
new hgweb was started; the killed hg wasn't completely dead yet.
Now we use killdaemons which waits for the process to die.
Due to the fix to the pull race, to avoid sending unnecessary
changesets, use changegroupsubset if possible.
This will increase the load on the server.
hg export -o outfile 1 2 3 4 had the same effect as hg -o outfile 4
This was caused by opening with 'w' instead of 'a'. This only occurs when
the filename pattern resulted in ambiguous patch filenames.
Using the changectx might result in a lookup error during the strip command.
Thefore we use the current dirstate to get the parents of the working directory.
When a manifest has a series of directories with nothing in them but a single
directory, displaying the entire chain of empty directories allows for
navigation down to the first non-empty directory with a single click.
Because Java links package hierarchy to directory hierarchy, and because Java
conventions include at least three empty directories at the top of this
hierarchy, descending down empty directories is very common in Java web tools.
When a file is deleted via hg rm <file> the dirstate marks the file with a
status of 'r'. The physical file has been deleted, but the inotify server
tries to do a stat on the file after it's been removed.
Patch catches the exception and correctly call updatestatus()
changegroup() has a problem when nodes which does not descend from a node
in <bases> are added to remote after the discovery phase.
If that happens, changegroup() won't send the correct set of nodes, ie.
some nodes will be missing.
To correct it we have to find the set of nodes that both remote and self
have (called <common>), and send all the nodes not in <common>.
This fix has some overhead, in the worst case it will re-send a whole branch.
A proper fix to avoid this overhead might be to change the protocol so that
the <common> nodes are sent (instead of the <bases> of the missing nodes).
* adds a new entry 'fncache' to '.hg/requires' for new repos
* writes new file '.hg/store/fncache'
* hash-encodes filenames with long paths (issue839)
* encodes Windows reserved filenames (issue793)
In 'hg', we now show a short list of commands, including extension commands.
In 'hg help', we show core commands, a list of enabled extensions, and topics.
pmezard expects
hg qref -s -X b
to apply the -X to the list of files in the patch, and thus remove b from the
patch.
That's how it worked before c302ef4372b2. That change seemed sensible, but it
wasn't...
mpm says
(17:22:30) pmezard_: kiilerix1: do you mean that -X should be forbidden with -s ?
(17:22:54) pmezard_: kiilerix1: and --include too
(17:23:03) mpm: No because you should be able to say hg qref -s foo* -X foo-bar
so mpm expects
hg qref -s -X b *
to apply the -X to the list of files in the working directory, and thus don't
include b in the patch
This patch tries to make both usecases work by creating a matchfn which uses
the include/excludes but not the filelist.
Some SUSE version don't like --home, they fail with:
"error: must supply either home or prefix/exec-prefix -- not both"
this is due to SUSE shipping a distutils.cfg conflicting with --home.
If we can't create the unix socket because the path is too long
we create the socket in a temporary directory and symlink it into
the repo.
Fix issue1208
The "real" way to test this is to mount a non-symlink-capable filesystem, and
try working on it; however, I don't know how to mount filesystems as a
non-priveleged user from within the testing framework. So instead, os.symlink
is overridden to raise the exception that would be raised on such a filesystem.
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.