While hopefully atypical, there are reasons that a subrepository revision can be
lost that aren't covered by corruption of the .hgsubstate revlog. Such things
can happen when a subrepo is amended, stripped or simply isn't pulled from
upstream because the parent repo revision wasn't updated yet. There's no way to
know if it is an error, but this will find potential problems sooner than when
some random revision is updated.
Until recently, convert made no attempt at rewriting the .hgsubstate file. The
impetuous for this is to verify the conversion of some repositories, and this is
orders of magnitude faster than a bash script from 0..tip that does an
'hg update -C $rev'. But it is equally useful to determine if everything has
been pulled down before taking a thumb drive on the go.
It feels somewhat wrong to leave this out of verifymod (mostly because the file
is already read in there, and the final summary is printed before the subrepos
are checked). But verifymod looks very low level, so importing subrepo stuff
there seems more wrong.
$TESTDIR is added to the path, so this is superfluous. Also,
inconsistent use of quotes means we might have broken on tests with
paths containing spaces.
addchangegroup creates a runhook function that is used to invoke the
changegroup and incoming hooks, but at the time the function is called,
the contents of hookargs associated with the transaction may have been
modified externally. For instance, bundle2 code affects it with
obsolescence markers and bookmarks info.
It also creates problems when a single transaction is used with multiple
changegroups added (as per an upcoming change), whereby the contents
of hookargs are that of after adding a latter changegroup when invoking
the hook for the first changegroup.
There are currently two different tests using roughly the same code to
create temporary scripts acting as HTTP servers. As there is going to
be at least one more in an upcoming change, factor those out in a
standalone dumbhttp.py script.
We cannot read $! to get the background job process identifier, with
MinGW it can return internal identifiers not matching the native Windows
ones. Instead we introduce a helper script polling on the pid file. We
assume the pid file data will be written in order.
Subrepositories used to be created empty and then filled with data
using pull. This is wasteful when you do a clone from a local source
since it means that no hardlinks are created for the subrepos.
This patch make the hgsubrepo._get method check for an empty subrepo
and in that case do a clone instead of a pull. This brings in the same
data as before, but creates hardlinks when possible.
The generation of cache files like tags.cache and branchheads.cache is not an
actual reflection of things changing in the whole of the .hg directory (like eg
a commit or a rebase or something) but instead these cache files are just part
of bookkeeping. As such its convienant to allow various clients to ignore file
events to do with these cache files which would otherwise cause a double
refresh. Eg one refresh might occur after a commit, but the act of refreshing
after the commit would cause Mercurial to generate a new branchheads.cache which
would then cause a second refresh, for clients.
However if these cache files are moved into a directory like eg .hg/cache/ then
GUI clients on OSX (and possibly other platforms) can happily ignore file events
in this cache directory.
Tracked files starting with a period in the name begin with '~2e' in the
store for the dotencode repository format, which is encoded as '%7E2e' in
URLs when accessing the repo over static-http.
The spaces in filenames are encoded with %20 in URLs.
See also issue 2566.
- signal handlers take two arguments, not one
- add missing import sys
Before this patch, the
$ kill $!
at the end of the test just caused a hidden traceback, sys.exit(0) was not
executed.
The swallowed traceback was:
Traceback (most recent call last):
File "dumb.py", line 10, in <module>
run()
File "dumb.py", line 7, in run
httpd.serve_forever()
File "/usr/lib/python2.6/SocketServer.py", line 224, in serve_forever
r, w, e = select.select([self], [], [], poll_interval)
TypeError: <lambda>() takes exactly 1 argument (2 given)
When issuing `hg pull -r REV` in a repo with no common ancestor with the
remote repo, the message 'requesting all changes' is printed, even though only
the changese that are ancestors of REV are actually requested. This can be
confusing for users (see
http://www.selenic.com/pipermail/mercurial/2010-October/035508.html).
This silences the message if (and only if) the '-r' option was passed.