Dates and times that are outside the 31-bit signed range are now
compared modulo 2^31. This should prevent it from behaving badly with
very large files or corrupt dates while still having a high
probability of detecting changes.
a0d2da57b726 added this help text to hg bookmark:
If no NAME is given, the current active bookmark will be marked inactive.
But that was never actually the case.
Originally spotted by Idan Kamara <idankk86@gmail.com>.
For example LC_ALL=de_DE.utf-8 would cause the version check to fail,
because "svn, Version 1.6.12 (r955767)" with a capital "V" will be printed.
Using "svn --version --quiet" would only print the version number, but then
matching other messages, e.g. "Committed revision" would fail.
Suppose the following scenario:
1. Process A takes the lock (e.g. on commit).
2. Process B wants to grab the lock. Since lock file exists
the exception is raised. In the catch block the testlock
function is called.
3. Process A releases the lock.
4. Process B tries to read the lock file as a part of testlock
function. This results in OSError (ENOENT) and since we're
not inside the exception handler function this is propagated
and aborts the whole operation.
To fix this we now check in testlock function whether lock file
actually exists and if not (i.e. if readlock fails) we just return.
We give up using CPython's PythonXX.lib import libraries (and Python.h), and
now "manually" call the LoadLibrary() / GetProcAddress() Windows API's instead.
If there is a "hg-python" subdirectory (the canonical directory name for
HackableMercurial's private Python copy) next to the hg.exe, we load the
pythonXX.dll from there (feeding an absolute path to LoadLibrary) and we set
Py_SetPythonHome() to that directory, so that the Python libraries are used
from there as well.
If there is no "hg-python" subdir found next to the hg.exe, we do not feed an
absolute path to LoadLibrary. This continues to allow to find a globally
installed Python DLL, as before this change - that is, without having to edit,
delete, rename, or configure anything.
Note that the hg.exe built is still bound to a *specific* major version of the
pythonXX.dll (e.g. python27.dll). What version it is, is inferred from the
version of the python interpreter that was used when calling setup.py. For
example
C:\python27_x86\python.exe setup.py build_hgexe -i --compiler=mingw32
builds a hg.exe (using the mingw32 tool chain) bound to (x86) Python 2.7. And
C:\python27_x86\python.exe setup.py build_hgexe -i
builds the same using the Microsoft C compiler/linker. (Note that the Microsoft
toolchain combined with x64 CPython can be used to build an x64 hg.exe.)
setup.py is changed to write the name of the pythonlib into the generated header
file "mercurial/hgpythonlib.h", which is #included by exewrapper.c. For a Python
2.7 build, it for example contains:
#define HGPYTHONLIB "python27"
exewrapper.c then uses HGPYTHONLIB for the name of the Python dll to load.
We don't want to track mercurial/hgpythonlib.h, so we add it to .hgignore.
This patch invokes "os.path.isdir()" via "rawvfs" object to avoid
filename encoding, because the path passed to "os.path.isdir()"
shouldn't be encoded.
This patch newly adds "self.rawvfs" field only to "basicstore" and
"encodedstore", because "fncachestore" has "self.rawvfs" already.
This patch replaces invocation of "getsize()", which calls "os.stat()"
internally, by "vfs.stat()".
The object referred by "self.rawvfs" is used internally by
"_fncachevfs" and doesn't encode filename for each file API invocation.
This patch invokes "os.stat()" via "self.rawvfs" to avoid redundant
filename encoding: invocation of "os.stat()" via "self.vfs" hides
filename encoding and encoding result from caller, so it is not
appropriate, when both encoded and non-encoded filenames should be
yield.
Even though changeset 89eacc6262af improved stream_out performance by
"self.pathsep + path", this patch replaces it by
"os.path.join(self.base, path)" of vfs. So, this may increase cost to
join path components.
But this shouldn't have large impact, because:
- such cost is much less than cost of "os.stat()" which causes
system call invocation
- "datafiles()" of store object is invoked only for "hg manifest
--all" or "hg verify" which are both heavy functions
This just replaces "os.stat()" invocation: refactoring around
"self.createmode" and "vfs.createmode" initialization is omitted.
This patch also newly adds "stat()" function to "abstractvfs".
This patch defines "join()" in each classes derived from "abstractvfs"
except "vfs", which already defines it.
This allows all vfs instances to be used for indirect file API
invocation.
This patch initializes "vfs" field in the constructor of each store
classes to use it for initialization of others.
In this patch, "self.vfs.base" is used to initialize "self.path",
because redo join of path components for "self.path" is redundant.
Definition functions for vfs support in dictionary order increases
readability/maintainability, because there are functions which invoke
file API:
- with same name: "os.listdir" and "osutil.listdir", for example
- with ambiguous names: "os.mkdir" and "util.makedirs", for example
Before this patch, there are two ambiguous variables: "havemf" and
"hasmanifest".
"havemf" means whether there are any "manifest" entries.
"hasmanifest" means whether there are any "changelog" entries
referring to "manifest" entry.
This patch renames from "hasmanifest" to "refersmf" to clear
difference from "havemf".
Before this patch, "checkentry()" internal function uses both
"node"(argument of itself) and "n"(defined in outer of it) variables.
Because all callers of "checkentry()" use "n" to refer the object
which is passed to "checkentry()" as "node", both can refer same
object in "checkentry()". So, "checkentry()" works correctly.
But such usage is not good for independence of "checkentry()".
This patch replaces "n" in "checkentry()" with "node".
Before this patch, verify module shows verification error message
below:
unknown parent 2 <HASH_OF_P2> of <HASH_OF_P1>
even though it should show:
unknown parent 2 <HASH_OF_P2> of <HASH_OF_TARGET>
This patch uses appropriate node information.
Before this patch, there is no information about what users should (or
can) do for recovery from corruption of repositories.
This patch adds URL of the Mercurial Wiki page explaining about
recovery from corruption.
Tags initially prevented revision to be hidden. It seemed a bad idea to have
tags refer to revisions that one can't see. But proper filtering of hidden
revisions excludes them from tag computation. Coming changelog filtering will do
that. Anyway, tags that really matter will likely be public and therefore not
hidden.
The current working directory parent and bookmarked revision are still not
hidden. Bookmarks were likely automatically moved at rewrite time, bookmarks
that remain on obsolete revisions were probably moved there on purpose.
If there are filtered changesets the cache is not valid. We'll have to cache
branchmap for filtered state too, but for now recomputing the branchmap is
enough.
svn --version --quiet is implemented since svn 0.14.1 (August 2002)
and prints just the version number, not the long output (21 lines)
of "svn --version".
Additionally I expect this output format to be more stable, at least
it is not changed with different translations.
If the input path is already longer than _maxstorepathlen, then we can skip
doing the basic encoding (encodedir, _encodefname and _auxencode) and directly
proceed to the hashed encoding. Those encodings, if at all, will make the path
only longer.
This changeset allows changelog object to be "filtered". You can assign a set of
revision numbers to the `changelog.filteredrevs` attributes. The changelog will
then pretends these revision does not exists in this repo.
A few methods need to be altered to achieve this behavior:
- tip
- __iter_
- irevs
- hasnode
- headrevs
For consistency and to help debugging, the following methods are altered too.
Tests tend to show it's not necessary to alter them but have them raise proper
exception helps to detect bad acces to filtered revisions.
- rev
- node
- linkrev
- parentrevs
- flags
The following methods would also need alteration for consistency purpose but
this is non-trivial and not done yet.
- nodemap
- strip
The C version of headrevs is not run if there is any revision to filter. It'll
need a proper rewrite later to restore performance.
Make the pure python implementation of headrevs available to derived classes. It
is important because filtering logic applied by `revlog` derived class won't
have effect on `index`. We want to be able to bypass this C call to implement
our own.
This prepares changelog level filtering. We can't assume that any revision can
be heads because filtered revisions need to be excluded.
New algorithm:
- All revisions now start as "non heads",
- every revision we iterate over is made candidate head,
- parents of iterated revisions are definitely not head.
Filtered revisions are never iterated over and never considered as candidate
head.
This prepares changelog level filtering. We need the algorithms used in revlog to
work on a subset of revisions. To achieve this, the use of explicit range of
revision is banned. `range` and `xrange` calls are replaced by a `revlog.irevs`
method. Filtered super class can then overwrite the `irevs` method to filter out
revision.
We can only use copy clone if the cloned repo do not have any secret changeset.
The current method for that is to run the "secret()" revset on the remote repo.
But with proper filtering of hidden or unserved revision by the remote this
revset won't return any revision even if some exist remotely. This changeset
adds an explicit function to know if a repo have any secret revision or not.
The other option would be to disable filtering for the query but I prefer the
approach above, lighter both regarding code and performance.
The forced recomputation of the branch cache was introduced by `b4909adfc093`.
Back there, `addchangegroup` did not handle any lock logic.
Later `6042c410e045` introduced lock logic to `addchangegroup`. Its description
does not explain why the `updatebranchcache` call is made outside locking. I
believe that the lock was released there because it fit well with the transaction
release already in the code.
Finally `1eda82d76f0c` moved all "unlocked" code of `addchangegroup` to an
`repo._afterlock` callback.
I do not think that the call to `updatebranchcache()` requires to be done
outside locking. That may even be a bad idea to do so. Bringing this call back
in the `addchangegroup` function makes the flow simpler and eases the following
up changelog level filtering business.
