This test is guarded by a '#if no-windows', but they can't be written out on
vfat on Linux either. con.xml can, and for testing that's good enough.
Also clean up a stray 'ls' that I mistakenly left in while writing the test.
If the "-r" argument is specified to "hg push," the user has expressed
an intent for a specific changeset to be present on the remote. If that
expression cannot be mapped to a known changeset, the user's intent is
ambiguous and cannot be acted upon without making assumptions.
Previously, if arguments to `push -r <rev>` evaluated to an empty set
(perhaps the user specified a revset that didn't evaluate to anything),
the empty "revs" list would be passed down to "exchange.push" where
it appears the empty list was being interpreted as "push everything."
This patch adds validation to the "-r" argument to the push command. If
the argument is specified but doesn't resolve to a changeset, the
command will abort instead of doing something potentially unexpected.
This patch is technically breaking backwards compatibility. I believe
this is justified because the new behavior closes a crack that could
result in undefined or under-defined behavior. Also, this patch doesn't
drop client capabilities because if users really wanted to push all
changesets, they can simply omit the "-r" argument from push completely.
'fcntl', 'termios' and 'wcurses' are not available on the default Windows python
installation, and importing them caused widespread carnage in the test suite.
There were 29 different changed test files (on top of unrelated errors), mostly
in the form of an ImportError.
The failures weren't related to actual crecord use, and followed the import
chain:
'localrepo' -> 'subrepo' -> 'cmdutil' -> 'crecord' -> 'fcntl'
The main purpose of wdir() is to annotate working-directory files.
Currently many commands and revsets cannot handle workingctx and may raise
exception. For example, -r ":wdir()" results in TypeError. This problem will
be addressed by future patches.
We could add "wdir" symbol instead, but it would conflict with the existing
tag, bookmark or branch. So I decided not to.
List of commands that will potentially support workingctx revision:
command default remarks
-------- ------- -----------------------------------------------------
annotate p1 useful
archive p1 might be useful
cat p1 might be useful on Windows (no cat)
diff p1:wdir (default)
export p1 might be useful if wctx can have draft commit message
files wdir (default)
grep tip:0 might be useful
identify wdir (default)
locate wdir (default)
log tip:0 might be useful with -p or -G option
parents wdir (default)
status wdir (default)
This patch includes minimal test of "hg status" that should be able to handle
the workingctx revision.
Paths into the subrepo are not yet supported.
The need to use the workingctx in the subrepo will likely be used more in the
future, with the proposed working directory revset symbol. It is also needed
with archive, if that code is to be reused to support 'extdiff -S'.
Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
as it breaks various status and diff tests.
I opted not to pass the desired revision into the subrepo method explicitly,
because the only ones that do pass an explicit revision are methods like status
and diff, which actually operate on two contexts- the subrepo state and the
explicitly passed revision.
This has mostly the same semantics as the files that the 'ui.portablefilenames'
config option would warn or abort about. The only difference is filenames that
case-fold to the same string -- given a set of filenames we've already
checked we can check whether a new one collides with them, but we don't have a
way to tell which filename it collided with.
This patch adds utility function "summary()", to replace comparing
bookmarks in "commands.summary()". This replacement finishes
centralizing the logic to compare bookmarks into "bookmarks.compare()".
This patch also adds test to check summary output with
incoming/outgoing bookmarks, because "hg summary --remote" is not
tested yet on the repository with incoming/outgoing bookmarks.
This test uses "(glob)" to ignore summary about incoming/outgoing
changesets.
This has several advantages compared to resolving it relative to the root:
- '--prefix .' works as expected.
- consistent with upcoming 'hg diff' option to produce relative patches
(I made sure to put in the (glob) annotations this time!)
Nobody should start a transaction on an unlocked repository. If
developer warnings are enabled this will be reported. This use the
same config as bad locking order since this is closely related.
When both '.' (the working copy root) and an explicit file (or files)
are in match.files(), we only walk the explicitly listed files. This
is because we remove the '.' from the set too early. Move later and
add a test for it. Before this change, the last test would print only
"3".
Previously we would only actually write the revbranchcache to disk if we were in
the middle of a write operation (like commit). Now we will also write it during
any read operation. The cache knows how to invalidate itself, so it shouldn't
become corrupt if multiple writers try at once (and the write-on-read
behavior/risk is the same as all our other caches).
The revbranchecache code already handled the case when the cache file wasn't
writable, but let's add a test as well so future changes don't regress this.
"working directory" is the standard term, we should use it consistently.
But I didn't touch the hint, "run 'hg update' to get a working copy", because
"get a working directory" sounds a bit odd.
When run on Windows, this test aborts:
@@ -20,7 +20,8 @@
> X
> EOF
$ hg commit -i -m "a" -d "0 0"
- no changes to record
+ abort: No module named fcntl!
+ [255]
$ hg tip
changeset: -1:000000000000
tag: tip
Maybe there's another way to get the screen size on Windows (it dies in
crecord.gethw()), but for now, quiet the test noise by skipping it if terminal
info compiler is unavailable.
OS X 10.6.8 doesn't have it, while 10.10 does. I'm not sure when it was added.
It may be missing from other platforms as well.
This currently doesn't handle the string manipulation options (-f, -s and -w in
MinGW anyway), since there is currently no need for it. Since xrange defaults
to starting at 0 instead of 1, and treats the end as exclusive instead of
inclusive, the args need to be extracted instead of doing:
xrange(*[int(a) for a in sys.argv[1:]])
Therefore, the step might as well be added, even though there is no current use.
Before this patch, "@number" suffixed bookmark may be newly created at
each "hg pull" from the remote repository, if the bookmark in remote
repository diverges from one in local one.
This causes unexpected increase of "@number" suffixed bookmarks.
This patch reuses "@number" suffixed bookmark, if it refers the
changeset which is referred by the same bookmark in the remote
repository.
Before this patch, "@99" suffixed bookmark may be updated unexpectedly
by the bookmark value on the remote side at "hg pull", if all of "@1"
to "@99" suffixed bookmarks exist in the local repository, because
variable "n" still refers "@99" suffixed bookmark after the loop to
examine "@num" suffixes, even though it already exists in the local
repository.
This patch prevents divergent bookmark from being updated
unexpectedly, and shows warning message in such situation.
This patch uses original python script "seq.py" instead of "seq"
command to create sequence numbers in the test, because "seq" command
may not be available: it isn't defined in recent POSIX specification
(POSIX.1-2001 2013 Edition or XPG7)
These tests exercise the edge cases of exchanging censored commits between
censor-aware Mercurial clients. These tests do not extend to cover
backwards-compatible exchange; such tests require a script which builds older
versions of Mercurial.
For more background on the censorship feature design, see:
http://mercurial.selenic.com/wiki/CensorPlan
The censor command is a core extension which can replace the contents of a
historical file revision with a censor "tombstone" which can be exchanged
with older clients in place of the real revision data. The command rewrites
the filelog by copying revision-by-revision.
Care must be taken to expand the fulltext of the children of the censored
revision before copying them to the new filelog; they might be stored as
deltas against the uncensored revision, and those deltas will be invalidated.
For more background on the censorship feature design, see:
http://mercurial.selenic.com/wiki/CensorPlan
This resolves the last breakage in run-tests that prevented me from
running a single test many times in several threads in parallel. This
will be useful for testing potential fixes to flaky tests.
There's a fair amount of mutable state stored on test case
instances. That causes many weird failures if you try to do something
like `run-tests.py -j16 --loop test-help.t`. The quick fix is this
slightly weird test-reloading dance, which ensures that every time a
test is executed it runs on a fresh instance of the TestCase subclass.
This is useful when you're working with a flaky test and want to run
it (for example) 500 times to see if it'll false-fail. This currently
breaks if you use it with more than one thread, but I'm looking into
that now.
For merges, we walk the files N-1 times, where N is the number of
parents. This means that for an octopus merge with 3 parents and 2
changed files, we actually fetch 6 files. This corrects the progress
output of the convert command when such commits are encountered.
A style name should not contain "/", "\", "." and "..". Otherwise, templates
could be loaded from outside of the specified templates directory by invalid
?style= parameter. hgweb should not allow such requests.
This change means subdir/name is also rejected.
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
After adding some sneaky debug printing[0], I determined that this
test flaked when a CVS commit containing two files starts too close to
the end of a second, thus putting file "a" in one second and "b/c" in
the following second. The secondary sort key meant that these changes
sorted in a different order when the timestamps were different than
they did when they matched. As far as I can tell, CVS walks through
the files in a stable order, so by sorting on the filenames in cvsps
we'll get stable output. It's fine for us to switch from sorting on
the branchpoint as a secondary key because this was already the point
when we didn't care, and we're just trying to break ties in a stable
way. It's unclear to be if having the branchpoint present matters
anymore, but it doesn't really hurt to leave it.
With this change in place, I was able to run test-convert-cvs over 650
times in a row without a failure. test-convert-cvcs-synthetic.t
appears to still be flaky, but I don't think it's *worse* than it was
before - just not better (I observed one flaky failure in 200 runs on
that test).
0: The helpful debug hack ended up being this, in case it's useful to
future flaky test assassins:
--- a/hgext/convert/cvsps.py
+++ b/hgext/convert/cvsps.py
@@ -854,6 +854,8 @@ def debugcvsps(ui, *args, **opts):
ui.write(('Branch: %s\n' % (cs.branch or 'HEAD')))
ui.write(('Tag%s: %s \n' % (['', 's'][len(cs.tags) > 1],
','.join(cs.tags) or '(none)')))
+ if cs.comment == 'ci1' and (cs.id == 6) == bool(cs.branchpoints):
+ ui.write('raw timestamp %r\n' % (cs.date,))
if cs.branchpoints:
ui.write(('Branchpoints: %s \n') %
', '.join(sorted(cs.branchpoints)))
This was accidentally fixed by other work, but given that it's been
broken in the past, I'd like to have a test defending us against
regressions in this area, especially as we add more functionality to
histedit.
The _lazymanifest type(s) behave very much like a sorted dict with
filenames as keys and (nodeid, flags) as values. It therefore seems
surprising that its __iter__ generates 3-tuples of (path, nodeid,
flags). Let's make it match dict's behavior of generating the keys
instead, and add a new iterentries method for the 3-tuples. With this
change, the "x" in "if x in lm" and "for x in lm" now have the same
type (a filename string).
Before this change, amending a merge would lose the rename information for file
adding in the second parents and implicitly renamed into a new directory.
In case of the merge, we also look for directory rename data from the second
parent. This seems to fix the bug and does not show other issues from the test
suite.
The next patch will enable verification by using the system's CA store if
possible, which means we would have to distinguish None (=use default) from
'' (=--insecure). This smells bug-prone and provides no way to override
web.cacerts to forcibly use the system's store by --config argument.
This patch changes the meaning of web.cacerts as follows:
value behavior
------- ---------------------------------------
None/'' use default
'!' never use CA certs (set by --insecure)
<path> verify by the specified CA certificates
Values other than <path> are for internal use and therefore undocumented.
