This behavior didn't make much sense and interacts badly with things
that use unbundle internally like shelve. Presumably, the original
rationale was that since bundles didn't contain bookmarks, this gave a
sense of keeping bookmarks up-to-date like would happen with a
corresponding pull. However, since it only updated the current active
bookmark, and bare update already did that anyway, this is pretty
slim.
Notably, the corresponding test actually works better without this
feature.
dirstate.normal is the method that marks files as unchanged/normal.
Rev 03dc7365e275 started caching dirstate.normal in order to improve
performance. However, there was an error in the patch: taking the wlock, under
some conditions depending on platform, can cause a new dirstate object to be
created. Caching dirstate.normal before calling wlock would then cause the
fixup calls below to be on the old dirstate object, effectively disappearing
into the ether.
On Unix and Unix-like OSes, the condition under which we create a new dirstate
object is 'the dirstate file has been modified since the last time we opened
it'. This happens pretty rarely, so the object is usually the same -- there's
little impact.
On Windows, the condition is 'always'. This means files in the lookup state are
never marked normal, so the bug has a serious performance impact since all the
files in the lookup state are re-read every time hg status is run.
When reversing a status, trading "added" and "removed" make sense.
Reversing "deleted" and "unknown" does not. We stop doing it.
The reversing is documented in place for the poor soul not even able to remember
the index of all status elements by heart.
By the magic of code movement, we ended up dropping unknown and ignored
information when comparing the working directory with a non-parent revision.
Let's stop doing it and add a test.
Changeset 83ad0e76acc0 introduced a test to validate that file were not reported
twice when both unknown and removed. This behavior change was introduced by
64d05ea3a10f alongside a bug that dropped ignored and unknown completely
(issue4321). As we are going to fix the bug, we need a proper implementation of
the behavior tested in 83ad0e76acc0.
Old behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic topic (!) - cmd
showconfig cmd topic (!) - cmd
rebase cmd cmd ext cmd
New behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic cmd - cmd
showconfig cmd cmd - cmd
rebase cmd cmd ext cmd
This patch makes the warning message for "patch --partial"
translatable: this message was introduced by a0ab8b02be69, and there is
no reason to prevent this from being translatable.
When using an editor path with spaces and options, you can set 'ui.editor'
to '"/path to your/editor" -opt' and it works fine but 'hg debuginstall'
is complaining about it because it simply splits the editor and
tests presence of '"/path'.
Now correctly parse 'ui.editor' string by handling quoted path.
This patch changes help text for "--edit" option of commands below:
- fetch
- qnew
- qrefresh
- qfold
- commit
- tag
This unification reduces translation cost, too.
This patch chooses not "further edit commit message already specified"
(of "hg commit") but "invoke editor on commit messages" as unified
help text for "--edit" option, because the latter is much older than
the former.
This patch changes help text for "--message" option of commands below
for unification.
- sign (of gpg)
- tag
This unification reduces translation cost, too.
This patch doesn't change the description for "--message" of "hg
rebase" below, because this should contain "collapse" word to explain
its purpose (only for "--collapse") clearly.
use text as collapse commit message
We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.
When a bundle2 parts generator returns a non callable value, it should not be
used as a reply handler. The changegroup part generator is already having this
case of behavior when there is no changegroup to push. This changeset prevent a
crash for user of the experimentable bundle2 feature.
With this change resolve and revert produce consistent output when run with no
arguments:
$ hg resolve
abort: no files or directories specified
(use --all to remerge all files)
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
f5a63a5506d2 regressed performance of baseset.__sub__ by introducing
a lazyset. This patch restores that lost performance by eagerly
evaluating baseset.__sub__ if the other set is a baseset.
revsetbenchmark.py results impacted by this change:
revset #6: roots(0::tip)
0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4)
1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100)
revset #23: roots((0:tip)::)
0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4)
1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61)
On the author's machine, this slowdown manifested during evaluation of
'roots(%ln::)' in phases.retractboundary after unbundling the Firefox
repository. Using `time hg unbundle firefox.hg` as a benchmark:
Before: 8:00
After: 4:28
Delta: -3:32
For reference, the subset and cs baseset instances impacted by this
change were of lengths 193634 and 193627, respectively.
Explicit test coverage of roots(%ln::), while similar to the existing
roots(0::tip) benchmark, has been added.
Setting substate to None was an oversight in 5b3c9729fe09 and this patch
corrects it by setting substate to an empty dictionary which matches what
subrepo code expects.
Even though "dirstate.write()" is invoked explicitly after "normal"
invocations, timestamp field of entries may be still "unset" in the
"dirstate" file itself , because "pack_dirstate" drops it when it is
equal to the timestamp of "dirstate" file itself.
This can avoid overlooking modification of files, which are updated at
same time in the second. But on the other hand, this may hide timing
critical problems.
For example, incorrect "normal"-ing (or lack of "normallookup"-ing on
the already "normal"-ed entry) is visible only when:
- the target file is modified in the working directory at T1, and
- "dirstate" file is written out at T2 (!= T1)
Otherwise, T1 is dropped by "pack_dirstate" in "dirstate.write()"
invocation, and "unset" is stored into "dirstate" file.
It often fails to reproduce problems from incorrect "normal"-ing by
Mercurial testset, because automated actions in the small repository
almost always causes that T1 and T2 are same.
This patch adds the debug feature to delay writing out to ensure
timestamp of each entries explicitly.
This feature is used to make timing critical "dirstate" problems
reproducable in subsequent patches.
This previously died in _revdescendants() taking the min() of the first set to
only(), when it was empty. An empty second set already worked. Likewise,
descendants() already handled an empty set.
This patch makes commit message shown in text editor customizable by
template. For example, this can advertise:
- sample commit messages for routine works,
- points to call attention before commit,
- message of the day, and so on
To show commit message correctly even in problematic encoding, this
patch chooses the latter below:
- replace "buildcommittext" with "buildcommittemplate" completely
- invoke "buildcommittemplate" only if '[committemplate] changeset'
is configured explicitly
For example, if multibyte character ending with backslash (0x5c) is
followed by ASCII character 'n' in the customized template, sequence
of backslash and 'n' is treated as line-feed unexpectedly (and
multibyte character is broken, too).
This corruption occurs in 'decode("string-escape")' while parsing
template string.
Add a new internal:tagmerge merge tool which implements an automatic merge
algorithm for mercurial's tag files
The tagmerge algorithm is able to resolve most merge conflicts that
currently would trigger a .hgtags merge conflict. The only case that
it does not (and cannot) handle is that in which two tags point to
different revisions on each merge parent _and_ their corresponding tag
histories have the same rank (i.e. the same length). In all other
cases the merge algorithm will choose the revision belonging to the
parent with the highest ranked tag history. The merged tag history is
the combination of both tag histories (special care is taken to try to
combine common tag histories where possible).
The algorithm also handles cases in which tags have been manually
removed from the .hgtags file and other similar corner cases.
In addition to actually merging the tags from two parents, taking into
account the base, the algorithm also tries to minimize the difference
between the merged tag file and the first parent's tag file (i.e. it
tries to make the merged tag order as as similar as possible to the
first parent's tag file order).
The algorithm works as follows:
1. read the tags from p1, p2 and the base
- when reading the p1 tags, also get the line numbers associated to each
tag node (these will be used to sort the merged tags in a way that
minimizes the diff to p1). Ignore the file numbers when reading p2 and
the base
2. recover the "lost tags" (i.e. those that are found in the base but not on p1
or p2) and add them back to p1 and/or p2
- at this point the only tags that are on p1 but not on p2 are those new
tags that were introduced in p1. Same thing for the tags that are on p2
but not on p2
3. take all tags that are only on p1 or only on p2 (but not on the base)
- Note that these are the tags that were introduced between base and p1 and
between base and p2, possibly on separate clones
4. for each tag found both on p1 and p2 perform the following merge algorithm:
- the tags conflict if their tag "histories" have the same "rank" (i.e.
length) _AND_ the last (current) tag is _NOT_ the same
- for non conflicting tags:
- choose which are the high and the low ranking nodes
- the high ranking list of nodes is the one that is longer.
In case of draw favor p1
- the merged node list is made of 3 parts:
- first the nodes that are common to the beginning of both the
low and the high ranking nodes
- second the non common low ranking nodes
- finally the non common high ranking nodes (with the last one
being the merged tag node)
- note that this is equivalent to putting the whole low ranking node
list first, followed by the non common high ranking nodes
- note that during the merge we keep the "node line numbers", which will
be used when writing the merged tags to the tag file
5. write the merged tags taking into account to their positions in the first
parent (i.e. try to keep the relative ordering of the nodes that come
from p1). This minimizes the diff between the merged and the p1 tag files
This is done by using the following algorithm
- group the nodes for a given tag that must be written next to each other
- A: nodes that come from consecutive lines on p1
- B: nodes that come from p2 (i.e. whose associated line number is None)
and are next to one of the a nodes in A
- each group is associated with a line number coming from p1
- generate a "tag block" for each of the groups
- a tag block is a set of consecutive "node tag" lines belonging to the
same tag and which will be written next to each other on the merged
tags file
- sort the "tag blocks" according to their associated number line
- put blocks whose nodes come all from p2 first
- write the tag blocks in the sorted order
Notes:
- A few tests have been added to test-tag.t. These tests are very specific to
the new internal:tagmerge tool, so perhaps they should be moved to their own
test file.
- The merge algorithm was discussed in a thread on the mercurial mailing list.
In http://markmail.org/message/anqaxldup4tmgyrx a slightly different algorithm
was suggested. In it the p1 and p2 tags would have been interleaved instead of
put one before the other. It would be possible to implement that but my tests
suggest that the merge result would be more confusing and harder to understand.
As extensively detailed by Pierre-Yves[1], simplemerge's minimal
markers can result in hopeless confusion for many common merges. As it
happens, we accidentally inherited this behavior when we borrowed
simplemerge from bzr; it is not the behavior used by RCS's merge(1),
Since merge(1) (and not bzr) is what we aim to emulate when emulating
RCS's merge markers, we simply turn this feature off. This brings us
in line with the behavior of CVS, SVN, and Git as a bonus.
(NB: using conflict markers with Mercurial is discouraged.)
[1] http://markmail.org/message/wj5mh3lc46czlvld
convert glob tessa
Before this patch, 'detailed' is used as the default of '[ui]
mergemarkers'. This embeds non-ASCII characters in tags, branches,
bookmarks, author and/or commit descriptions into merged files in the
encoding specified by '--encoding' global option, 'HGENCODING' or
other locale setting environment variables.
But, if files to be merged use another encoding, this behavior breaks
consistency of encoding in merged files.
For example, ISO-2022-JP or EUC-JP are sometimes used as the file
encoding for Japanese characters, because of historical and/or
environmental reasons, even though UTF-8 or Shift-JIS are ordinarily
used as the terminal encoding.
This can't be resolved automatically, because Mercurial doesn't aware
encoding of managed files.
This patch uses 'basic' as the default of '[ui] mergemarkers' to avoid
embedding encoding sensitive characters for safety.
This patch puts '[ui] mergemarkers = detailed' into default hgrc file
for tests, to reduce changes for tests in this patch.
Added "unexpected leading whitespace" message to parse error
when .hgrc has a line that starts with whitespace.
Helps new users unfamiliar with syntax of rc file.
We add a ``--record-parents`` flag to debugobsolete. This can be used to record
parent information in the marker when the precursors are known locally. This
will be useful to test the "relevant markers" computation.
We add a ``relevantmarkers`` method to fetch all markers that seem relevant to a
set of nodes. See function documentation about how this set is computed. This
will let us exchange only the markers that seem "relevant" to the set of
changesets related to a push or a pull.
The approach used to define "relevant" has been successfully tested in evolve
for 6 months.
We use the new `parents` field to build a dictionary of markers that touch
children of a node. This will be used to link prune markers to a set of
exchanged nodes.
We can now directly prevent any evolution-related operation from happening by using
an empty set for outgoing markers. So we detect if no transfers should occur and
use an empty set in this case.
Local clones copy/hardlink over files directly, so the branchcaches should all
be valid. There's a slight chance that a read operation would update one of the
branchcaches, but we hold a lock over the source repo so they shouldn't cause
an invalid branchcache to be copied over, just a different, valid one.
We now store the `parents` field on disk. We use the same strategy as for
`date`: We stick it into the metadata. This is slow and dirty, but this is also
the only way we currently have.
At some point we'll have a new obsstore format to store this properly.
We are extracting the `date` information from the metadata at read time.
However, we failed to remove it from the metadata returned in the markers. This
is now fixed.
We need this information to build the set of relevant markers during
exchanges. This can only be done at the `createmarkers` level since
the `obsstore.create` function does not have a repo and therefore has
no access to the parent information.
This field is intended to store the parent of the precursor. This is useful to
attach pruned changesets to a set of exchanged changesets. We currently just
add the fields with a None value. None stands for "no data recorded".
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "normal" and "merge" as ROUTE, to distinguish
merge commits from other.
This patch adds 4 test patterns to test combination of "merge"(x2) and
"--continue"(x2).
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "merge" as ROUTE, to distinguish merge commits
from other.
This patch passes bool as "ctxorbool" to "mergeeditform", because
working context has always 2 parents at this point. Dropping the
second parent of non-merging commits is executed in "concludenode".
Unlike other patches in this series (e.g. for "hg commit"), this patch
doesn't add "normal.normal"/"normal.merge" style ROUTEs, because there
is no "merge" case in "collapse" ROUTE.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
other in "hg import" without "--bypass" case.
This patch assumes "editform" variations for "hg import" below:
import.normal.normal
import.normal.merge
import.bypass.normal
import.bypass.merge
Unlike other patches in this series, this patch uses "editor.sh"
instead of "checkeditform.sh" for the name of the script to check
"HGEDITFORM", because it has to do more than checking "HGEDITFORM".
To invoke editor forcibly in "test-import-merge.t", this patch creates
the patch not having patch description as "merge.nomsg.diff".
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "amend.normal" and "amend.merge" as ROUTE of
"editform" instead of "amend", to distinguish merge commits from other
in "hg commit --amend" case.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
others in "hg commit" without "--amend" case.
This patch assumes "editform" variations for "hg commit" below:
commit.normal.normal
commit.normal.merge
commit.amend.normal
commit.amend.merge
"mergeeditform" is factored out for subsequent patches. It takes
"ctxorbool" argument, because context object can't be passed in some
cases.
On Linux, fstat().st_size of a pipe always returns 0, even if the
pipe has data available for reading. This meant that reading from
and subsequently printing the stderr pipe content after wireproto
commands over SSH meant that available data wasn't being printed.
We now implement pipe reading on POSIX by doing a non-blocking
read for all available data.
Reading all available data from a pipe has a platform-dependent
implementation.
This patch establishes platform.readpipe() by copying the
inline implementation in sshpeer.readerr(). The implementations
for POSIX and Windows are currently identical. The POSIX
implementation will be changed in a subsequent patch.
We use the `pushkey` part to exchange bookmark updates within the unified
bundle2 push. Note that this only applies on update (moving a bookmark known on both
sides) since bookmark export (creation of a new bookmark on remote) is apparently
done outside of the _push function.
The discovery of necessary bookmark updates is now done within the "discovery
phase". This opens the door to the inclusion of bookmarks in a unified bundle2
push.
We make a temporary variable for the remote bookmark data and we do not expand
all elements from `bookmark.compare` since we are going to use only one.
Before this patch, there was always an attempt to update bookmark even if prior
steps of the push failed. I cannot see a good semantic reason to do so. We
disable this possibility to simplify the push flow with bundle2. Bookmarks will
be included in the bundle and fail with other steps.
Now that ancestors has the same boolean property as a list, we can stop unrolling
the set of ancestors. This should provide a significant speedup to this step as
ancestor objects are smart and lazy.
hgweb detects out-of-date repository instances (using a highly
suspect mechanism that should probably be fixed) and obtains a new
repository object if needed.
This patch changes the repository object copy to use the repo URL
(instead of path). This preserves more information about the source
repository and allows bundles to be served through hgweb.
A test verifying that bundles can now be served properly via
`hg serve` has been added.
The markers are now 5-item tuples (concluded by the date). The obsstore.fields
contents have been updated accordingly.
There is no change to the on-disk format yet, so the date has to be extracted
every time we read binary markers and re-injected each team we write them. This
introduces a slowdown that will be solved when a new version of the format is
added. Such a slowdown was already introduced by the evolve extension anyway.
We are going to increase the amount of data explicitly stored in obsolescence
markers. This mean we are going to have a longer tuple and some values will be
shuffled around. So we add a ``fields`` attribute to the obsstore class to
keep track of what entry is what. This will be useful for extensions and for
documentation purpose.
The date will become an official field in the markers (and ultimately
in the on-disk format). We start by making it an official argument for
the function.
We are about to add more arguments to this function (date, parents, etc).
Passing metadata as a keyword argument gives us more flexibility when adding
them.
We check for rename information in the dirstate. This is probably not enough to
preserve this behavior when using an explicit target rev.
I just spotted this while working on this code, but this is outside the scope
of my series so I'm just adding a comment to highlight this suspicious
situation.
All those checks were here to catch cases where files were not modified in
dirstate but were different in the target revision. This is now properly handled
by calling status on the target node too.
In case of merge, file that are actually added can be reported as modified. This
is currently handled by special-case code. We detect it beforehand instead. This
will lets use remove the special-case code at some point in the future.
There are multiple possible cases for added files. But it's all handled by magic
much lower in the stack. We document them, simplify the codes and move on.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
In all the remaining cases the comprehension variable is used for the same
thing as a previous loop variable.
This will mute some pyflakes "list comprehension redefines" warnings.
_ is usually used for i18n markup but we also used it for I-don't-care
variables.
Instead, name don't-care variables in a slightly descriptive way but use the _
prefix to designate unused variable.
This will mute some pyflakes "import '_' ... shadowed by loop variable"
warnings.
Using status information against the target ensures we are catching all
files with modifications that need reverting.
We still need to distinguish fresh modifications for backup purpose.
test-largefile is affected because it reverted a file that needs no content
change.
We had a special case for file not caught by any categories. It was
aimed at files missing in wc and wc's parent but existing in the target
revision. This is now properly handled using status information.
Using status information against the target to make sure we are catching all
files that need to be re-added.
We still need to distinguish fresh removal because they use a different
message.
Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.
This fixes a couple of test outputs where the lack of changes was not reported.
Status can return file as "deleted". This is only a special case
related to working directory state: file is recorded as tracked but no
file exists on disk. This will never be a state obtainable from
manifest comparisons.
"Deleted" files have another working directory status shadowed by the lack of
file. They will -alway- be touched by revert. The "lack of file" can be seen as
a modification. The file will never match the same "content" as in the revert
target. From there we have two options:
1. The file exists in the target and can be seen as "modified".
2. The file does not exist in the target and can be seen as "added".
So now we just dispatch elements from delete into appropriate categories.
The output is slightly changed because of minirst formatting. Previously,
ui.pushbuffer() had no effect because "badalias" message was written to stderr.
"if not unknowncmd" should no longer be needed because there's no call loop.
Before this patch, there was no way to pass in all the positional parameters as
separate words down to another command.
(1) $@ (without quotes) would expand to all the parameters separated by a space.
This would work fine for arguments without spaces, but arguments with spaces
in them would be split up by POSIX shells into separate words.
(2) '$@' (in single quotes) would expand to all the parameters within a pair of
single quotes. POSIX shells would then treat the entire list of arguments
as one word.
(3) "$@" (in double quotes) would expand similarly to (2).
With this patch, we expand "$@" (in double quotes) as all positional
parameters, quoted individually with util.shellquote, and separated by spaces.
Under standard field-splitting conditions, POSIX shells will tokenize each
argument into exactly one word.
This is a backwards-incompatible change, but the old behavior was arguably a
bug: Bourne-derived shells have expanded "$@" as a tokenized list of positional
parameters for a very long time. I could find this behavior specified in IEEE
Std 1003.1-2001, and this probably goes back to much further before that.
When a file was marked as removed in the working copy and did not existed in the
target of the revert, we did not issued any message pointing that no change was
needed to the file (implicitly saying that revert had changed the file).
We now properly issue a message in this situation. Tests change in and handful
of case where the message was documented as missing.
We now call status against the target (and possibly against the working
directory parent is different). We do not use the information from the two
sources yet, but this is coming soon.
We need the status information aganst the dirstate in all case because we need
to be able to backup local modification.
As we are going to introduce status again other revision we needs to distinguish
between data from dirstate status and the other one. We prefix the existing data
with "ds" to highlight this.
Currently, revset is using information from dirstate status and alter its
behavior whenever the file exist in the target manifest or not. This tests are
done a big for loop. We move this member ship testing outside of the loop and
simplifies associates data structure.
This is a step toward a cleaner implementation of revert based on status.
Use the introduced caching infrastructure to cache hidden
changesets. We crosscheck if the content of the cache unless
experimental.verifyhiddencache is set to False. This will be removed
in the future. Without crosschecking the caches speed ups hg status and
other commands:
without caching:
$ time hg status
hg status 0.72s user 0.20s system 100% cpu 0.917 total
with caching
$ time hg status
hg status 0.49s user 0.15s system 100% cpu 0.645 total
Add a caching infrastructure to cache hidden changesets. The cache tries to read
the cache lazily and falls back to recomputing if no wlock can be obtain.
To validate the cache we store a sha of the obstore content and repo heads in
the beginning of the cache which we check every request.
Split up _gethiddenblockers into two categories: (1) "static' blockers
that solely rely on the contents of obstore and are visible children of
hidden changsets. (2) "dynamic" blockers, appearing by having wd parents,
bookmarks or tags pointing to hidden changesets.
We assume that (1) doesn't change often and can be easily cached with a good
invalidation strategy. (2) change often, but barely produce blockers, so we
can recompute them if necessary.
We used to have two slightly different message which people wouldn't read...
and then complain that they couldn't find the global options or examples.
So we unify them into one message that's upfront that STUFF IS
INTENTIONALLY HIDDEN and that looks more like our normal hint style.
The phase cache file is no longer written on lock release, it is now handled by
the transaction (as changesets and obsolescence markers are).
(Hooray)
As we stop relying on the lock to write phase, repos with no existing phase
information will need to wait for a phase move or a strip to happen in order to
get the first write in the `phaseroots` file. This explain the change in
test-inherit-mode.t.
This should not have any side effects but in very obscure cases where
people interact with pre-2.1 and post-2.1 versions of Mercurial on the
same repo while having MQ patches applied but the MQ extension
disabled from time to time. A case unlikely enough to not be worth
preserving the old behavior with awful hacks.
In most case, the file creation logic will be handled by the
transaction itself. The write method has to stay around for the case
where the repository is modified outside a transaction (strip).
A new `transaction.addfilegenerator` function is added. It allows external code
to register files to be generated. See inline documentation for details.
It is important to gather all file creation logic on the transaction
as at some point we'll want to mimic the "pre-transaction-commit"
logic that we use for revlog. I'm refering to the logic that lets
hooks see the result of the transaction before it actually gets
committed.
Similar to the previous patch for workingfilectx, this patch will allow
abstracting localrepo.remove / write method to refactor working directory code
but instead operate on files in memory.
We now pass a transaction option to this phase movement function. The
object is currently not used by the function, but it will be in the
future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
We now pass a transaction option to this phase movement function. The object
is currently not used by the function, but it will be in the future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
The retractboundary function remains to be upgraded.
We were relying on the phase internals to filter out redundant phase
information from remove. However as we plan to integrate phase
movement inside the transaction, we want to avoid useless transaction
creation on no-op pulls.
Therefore we filter out all the information that already matches the current
repository state. This will let us create a transaction only when there is
actual phase movement needed.
