This is the last step before supporting extdiff -S. It maintains the existing
behavior of diffing the largefile standins instead of the largefiles themselves.
Note however that the standins are not updated immediately upon modification, so
uncommitted largefile changes are ignored, as they previously were, even with
the diff command.
There are currently no users of this, but it is a necessary step before
converting extdiff to use archive. It may be useful to add an argument to
extdiff in the future and allow largefiles to be diffed, but archiving
largefiles can have significant overhead and may not be very diffable, so
archiving them by default seems wrong.
It is a mystery to me why the lfstatus attribute needs to be set on the
unfiltered repo. However if it is set on the filtered repo instead (and the
filtered repo is passed to the original command), the lfstatus attribute is
False in the overrides for archival.archive() and hgsubrepo.archive() when
invoking the archive command. This smells like the buggy status behavior (see
9fc565fa1621, which was reverted in e1574a4a2cad). Neither the status nor
summary commands have this weird behavior in their respective overrides.
Before this patch, we were stripping temporary commits at the end of a histedit
whether it was successful or not. If we can create obs markers, we should
create them instead of stripping because it is faster and safer.
We use a variable to store whether or not we can create obsolescence markers.
It makes the patch series more readable as we are going to reuse this
values in other places in the function.
Before this patch, censored file should be exactly "a path relative to
repository root" regardless of current working directory, because "hg
censor" passes "path" to "repo.file()" directly without any
preparations.
To make various path forms available like other Mercurial commands,
this patch gets a target file path in the way of "hg parents FILE".
Getting "wctx" is relocated to reuse "wctx" for efficiency.
A fix for issue2653 with f5abbf51a76e introduced a discrepancy how default
branch should be denoted when converting with branchmap from different SCM.
E.g. for Git and Mercurial you need to use 'default' whilst for Perforce and
SVN you had to use 'None'. This changeset unifies 'default' for such purposes
whilst falling back to 'None' when no 'default' mapping specified.
Before this patch, 'hg shelve -i' under non-interactive mode suggests
'use commit instead', and it obviously incorrect, because what user
wants to do isn't 'commit' but 'shelve'.
To omit incorrect 'commit' suggestion at 'hg shelve -i', this patch
specifies 'None' for 'cmdsuggest' argument of 'cmdutil.dorecord()'.
Before this patch, 'hg qrefresh -i' under non-interactive mode
suggests 'use qrefresh instead', and it obviously meaningless.
To omit meaningless 'qrefresh' suggestion at 'hg qrefresh -i', this
patch specifies 'None' for 'cmdsuggest' argument of 'cmdutil.dorecord()'.
Before this patch, 'hg qnew -i' under non-interactive mode suggests
'use qnew instead', and it obviously meaningless.
To omit meaningless 'qnew' suggestion at 'hg qnew -i', this patch adds
internal function '_qrecord()' and specifies 'cmdsuggest' for each of
'qrecord' and 'qnew' separately.
Before this patch, 'hg commit -i' under non-interactive mode suggests
'use commit instead', and it obviously meaningless.
This patch makes 'record.record'()' examine 'ui.interactive()' and
show suggestion by itself before calling 'commands.commit()'.
This allows 'commands.commit()' to specify 'None' for 'cmdsuggest'
argument of 'cmdutil.dorecord()' to omit meaningless 'commit'
suggestion at 'hg commit -i'.
Previously all git remotes were created as "remote/foo". This patch adds a
configuration option for deciding what the prefix should be. This is useful if
you want the bookmarks to be "origin/foo" like they are in git, or if you're
integrating with the remotenames extension and don't want the local remote/foo
bookmarks to overlap with the remote foo bookmarks.
When converting a particularly large Perforce changelist (especially with some
big files), it is very likely to run into an intermittent network issue (e.g.
WSAECONNRESET or WSAETIMEDOUT) getting one of the files, which will result in
the entire changelist converting being aborted. Which can be quite unfortunate
since you might have waited hours getting all other files. To mitigate this
let's attempt to get the file one more time, escalating original exception
if that attempt fails.
Before this patch, backups to be discarded are decided by steps below
at 'hg unshelve' or so:
1. list '(st_mtime, filename)' tuples of each backups up
2. sort list of these tuples, and
3. discard backups other than 'maxbackups' ones at the end of list
This doesn't work well in the case below:
- "sort by name" order differs from actual backup-ing order, and
- some of backups have same timestamp
For example, 'test-shelve.t' satisfies the former condition:
- 'default-01' < 'default-1' in "sort by name" order
- 'default-1' < 'default-01' in actual backup-ing order
Then, 'default-01' is discarded instead of 'default-1' unexpectedly,
if they have same timestamp. This failure appears occasionally,
because the most important condition "same timestamp" is timing
critical.
To avoid such unexpected discarding, this patch keeps old backups if
timestamp can't decide exact order of them.
Timestamp of the border backup (= the oldest one of recent
'maxbackups' ones) as 'bordermtime' is used to examine whether
timestamp can decide exact order of backups.
Many 3rd party consumers of Mercurial have created wrappers to
essentially perform clone+share as a single operation. This is
especially popular in automated processes like continuous integration
systems. The Jenkins CI software and Mozilla's Firefox release
automation infrastructure have both implemented custom code that
effectively perform clone+share. The common use case here is that
clients want to obtain N>1 checkouts while minimizing disk space and
network requirements. Furthermore, they often don't care that a clone
is an exact mirror of a remote: they are simply looking to obtain
checkouts of specific revisions.
When multiple third parties implement a similar feature, it's a good
sign that the feature is worth adding to the core product. This patch
adds support for an easy-to-use clone+share feature.
The internal "clone" function now accepts options to control auto
sharing during clone. When the auto share mode is active, a store will
be created/updated under the base directory specified and a new
repository pointing to the shared store will be created at the path
specified by the user.
The share extension has grown the ability to pass these options into
the clone command/function.
No command line options for this feature are added because we don't
feel the feature will be popular enough to warrant their existence.
There are two modes for auto share mode. In the default mode, the shared
repo is derived from the first changeset (rev 0) in the remote
repository. This enables related repositories existing at different URLs
to automatically use the same storage. In environments that operate
several repositories (separate repo for branch/head/bookmark or separate
repo per user), this has the potential to drastically reduce storage
and network requirements. In the other mode, the name is derived from the
remote's path/URL.
This creates the convert.hg.sourcename config option which will embed a user
defined name into each commit created by the convert. This is useful when using
the convert extension to merge several repositories together and we want to
record where each commit came from.
Previously convert could only take one '--rev'. This change allows the user to
specify multiple --rev entries. For instance, this could allow converting
multiple branches (but not all branches) at once from git.
In this first patch, we disable support for this for all sources. Future
patches will enable it for select sources (like git).
Mercurial uses tags of null to mark deletions, but convert was
silently discarding these because it had no mapping for them. Thus, it
was resurrecting deleted tags.
The check of the inrebase function was not correct, and it failed to
consider the situation in which nothing has been rebased yet, *and*
the working dir had been updated away from the initial revision.
But this is easy to fix. Given the rebase state, we know exactly where
we should be standing: on the first unrebased commit. We check that
instead. I also took the liberty to rename the function, as "inrebase"
doesn't really describe the situation: we could still be in a rebase
state yet the user somehow forcibly updated to a different revision.
We also check that we're in a merge state, since an interrupted merge
is the only "safe" way to interrupt a rebase. If the rebase got
interrupted by power loss or whatever (so there's no merge state),
it's still safer to not blow away the working directory.
If histedit failed after all the rules were complete (for instance, if there was
an exception in the cleanup phase), you couldn't --continue because it was
unable to pop a rule. Let's just skip the rule execution phase of --continue if
there are no more rules.
If the histedit backupfile was None (like if evolve is enabled) it would get
serialized as 'None' into the state file. Later if the histedit was aborted and
the top most commit was unreachable (ex: if it was obsolete or stripped),
histedit would try to unbundle the backupfile and try to read .hg/None.
This fixes it to not serialize None. Since it only happens with evolve, I'm not
sure how to add test coverage here.
--edit-plan was completely broken from the command line because it used an old
api that was not updated (it would crash with a stack trace). Let's update it
and add tests to catch this.
According to recent "filectx.data()" implementation, "censor.policy"
should be configured as "ignore" to ignore error at censored file:
"censor.allow" seems outdated name.
While fixing issue4304: "record: allow editing new files" we introduced
changes in record/crecord. These changes need to be matched with changes in any
command using record. Shelve is one of these commands and the changes have
not been made for this release. Therefore, shelve -i should be an experimental
feature for this release.
`hg pull` takes an optional "source" argument to define the path/url to
pull from. Under some circumstances, this option could get proxied to
rebase and interpretted as the --source argument to rebase, leading to
unexpected behavior.
In my local environment, "source" always appears in "opts" in
pullrebase. However, when attempting to write a test, I couldn't reproduce
this. Instead, the source is being captured as a positional argument in
"args." I suspect an interaction between **kwargs and an extension is to
blame for the differences in behavior. This is why no test has been
written.
I have tested behavior locally and the patch has the intended
side-effect of making `hg pull --rebase` work again.
We've had a couple reports of subversion tracebacks that trigger when
the parents list is empty, and thus block showing what the commit
failure was on the next two lines.
We want to capture hooks output during bundle2 processing. For this purpose we
introduce a new 'subproc' argument to 'ui.pushbuffer'. When set, the output of
sub process created through 'ui.system' will be captured in the buffer too.
This will be used in the next changeset.
Commit 960f8ca79ab1 broke histedit's rollup by causing it to open the editor.
Turns out I missed a spot where the rollup option was read.
This fixes that and adjusts the test to catch this case.
The error-handling here is quite byzantine. self._apply raises an
AbortNoCleanup, but self.apply was swallowing the exception and
returns 2. In self.push, we catch all exceptions.. and cleanup. We try
to print a message to clean up.. but that relies on having a
top-of-stack.
Instead, we re-raise the abort in self.apply, and avoid cleanup on
AbortNoCleanup in self.push by adding a trivial new except clause. We
also modernize the now-visible abort message.
