When the obsolete feature is enabled, histedit creates obsolescence marker
instead of stripping replaced changesets.
For now, we keep stripping temporary nodes created along the way.
This changeset rewrites the change tracking logic of histedit to record every
operation it does. Tracked operations record the full list of "old" node that
will eventually be removed to the list of new nodes that replace it. Operations
on temporary nodes are tracked too. Dropped changesets are also recorded as an
"old" node replacement by nothing. This logic is similar to the obsolescence
marker one and will be used for this purpose in later commit.
This new logic implies a big amount of change in the histedit code base.
histedit action functions now always return a tuple of
(new-ctx, [list of rewriting operations])
The old `created`, `replaced` and `tmpnodes` are no longer returned and stored
during histedit operation. When such information is necessary it is computed
from the replacement graph. This computation is done in the `processreplacement`
function.
The `replacemap` is also dropped. It is computed at the end of the command from the
graph. The `bootstrapcontinue` methods are altered to compute this different kind of
information.
This new mechanism requires much less information to be written on disk.
Note:
This changes allows a more accurate bookmark movement. bookmark on dropped
changeset are now move of their parent (or replacement of their parent)
instead of their children.
This fix issue3582
We are now checking for any changesets between the previous `parentctx` and the
current working directory parent. If the current working directory parent is
inconsistent, we abort.
This change is useful as it simplifies the --continue process, easing upcoming
changes.
While working on this changeset, I spotted an unhandled corner case. This corner
case is now documented and have an appropriate issue in the tracker (issue3655).
However, the corner case is still unhandled. handling this test case would
required some additional work:
- actually decide what the proper behavior should be:
- change content of "histedit-state" to add missing data necessary to detect
the situation
- add proper testcase,
But leaving the case unhandled is "okay":
- this is not a regression,
- this is not the purpose of the current series,
- the freeze was near and I had more critical stuff to attend to,
- this is a simple but non trivial, (see above)
This adds two new commands:
- analyze examines an existing repo and writes out a statistical
description of its properties that contains no identifying
information.
- synthesize creates new commits based on the description generated
by analyze.
The intention is that a repo constructed using synthesize will have
properties that are vaguely statistically similar to the originating
repo, but entirely random content.
This can be useful for forecasting performance as a repo grows, and
for developers who want to find bottlenecks in proprietary repos
to which they do not have access.
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.
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.
Bookmarks are updated during qpop and qpush, but they are not updated
during qrefresh. This behaviour makes it hard to work on an evolving
changeset at the head of a branch. qrefresh should update all bookmarks
that point to the refreshed commit with the new nodeid.
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.
The old calculation code failed to properly identify revs that
weren't tagged, leaving us with a version of "unknown" most of the
time during development.
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.
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.
Heredocs are usually fed to other commands and
shouldn't follow the standard conventions of shell
commands.
This restores the old behaviour of how heredocs
were handled in old-style test files.
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.
