Options like --delete and --rename are incompatible with each
other. In this case we abort. We do not abort if the result is a nullop.
Nullops are: '--delete --inactive', '--delete --force'.
This allows the user to set different colors for each phase, e.g.
[color]
changeset.public = blue
changeset.draft = green
changeset.secret = red
In addition, this doesn't affect current configuration for custom log.changeset
colors, but rather adds the option for users that want to visually see which
changesets are amendable.
We don't need to compute the set of all branchpoints. We can just check the
number of children that element of subset have. The extra work did not seems to
had particular performance impact but the code is simpler this way.
This makes sure that .hg/requires is observed and the correct kind of store
object is created. Otherwise we might mutilate our test repos when experimenting
with new repo formats.
After d5471ad04cf6 all \r was stripped from output on Windows, and the places
where a \r explicitly was expected it was accepted that it was missing. Ugly
hack.
Instead we now accept that an extra \r might appear at the end of lines on
Windows. That is more to the point and less ugly.
People were confused by the fact `obstore.precursors` contained marker allowing
to find "precursors" and vice-versa.
This changeset changes their meaning to:
- precursors[x] -> set(markers on precursors edges of x)
- successors[x] -> set(markers on successors edges of x)
Some documentation is added to clarify the situation.
Nullid as successors create multiple issues:
- Nullid revnum is -1, confusing algorithm that use revnum unless you add
special handling in all of them.
- Nullid confuses "divergent" changeset detection and resolution. As you can't
add any successors to Nullid without being in even more troubles
Fortunately, there is no good reason to use nullid as a successor. The only
sensible meaning of "succeed by nullid" is "dropped" and this meaning is already
covered by obsolescence marker with empty successors set.
However, letting some nullid successors to slip in may cause terrible damage in
such algorithm difficult to debug. So I prefer to perform and clear detection of
of such pathological changeset. We could be much smarter by cleaning up nullid
successors on the fly but it would be much for expensive. As core Mercurial does
not create any such changeset, I think it is fine to just abort when suspicious
situation is detected.
Earlier experimental version created such changesets, so there are some out
there. The evolve extension added the necessary logic to clean up its mess.
Maintain a whitelist of commands to infer the repo for instead. The whitelist
contains those commands that take file(s) in the working dir as arguments.
This changeset treats the bookmark "@" as a special case for the naming of
divergent bookmarks, as per the tables below. For the <no alias> case, the
actual suffix will vary, depending on what suffixes are already in use.
Before:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @@bar
@ | <no alias> | @@1
After:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @bar
@ | <no alias> | @1
This case is likely to be more common now that c1644655c164 has made the "@"
bookmark have special meaning to clone.
The change in behavior was discussed on the mailing list in the thread below:
http://markmail.org/thread/rwedgxp7le5j2h2f
We do not want hidden revision to block histedit. They are already "dead"
and we do not care about dead orphans. see similar changeset 40db49347807 for
rebase.
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
