Clone bundles require a well-defined string to specify the type of
bundle that is listed so clients can filter compatible file types. The
`hg bundle` command and cmdutil.parsebundletype() already establish the
beginnings of a bundle specification format.
As part of formalizing this format specification so it can be used by
clone bundles, we move the specification parsing bits verbatim to
exchange.py, which is a more suitable place than cmdutil.py. A
subsequent patch will refactor this code to make it more appropriate as
a general API.
After moving logic from 'merge.update' into 'destutil.destupdate', we are now
moving logic from 'command.update' in 'destutil.destupdate'. This will make the
function actually useful in predicting (and altering) the update behavior.
We want this function to exactly predict the behavior for update. Moreover, we
would like to remove all high level behavior logic out of the merge module so
this is a step forward.
Now that the 'destupdate' function both compute and validate the destination, we
can directly use it at the command level, ensuring that the 'hg update' command
never call 'merge.update' without a defined destination. This is a first (but
significant) step toward having 'merge.update' always feed with a properly
validated destination and free of high level logic.
The section of code that writes out the version of the file cached in the merge
state should only be run at preresolve time. This is so that if the premerge
keeps around conflict markers, those don't get overwritten before the main
merge.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
Before this patch, "hg backout" uses 'begin'/'end'-'parentchange()'
of 'dirstate' class to avoid writing incomplete dirstate changes out
at failure.
But this framework doesn't work as expected, if 'dirstate.write()' is
invoked between them. In fact, in-memory dirstate changes may be
written out at 'repo.status()' implied by 'merge.update()', even
before this patch.
To restore dirstate as expected at failure of "hg backout", this patch
uses 'dirstateguard' instead of 'begin'/'end'-'parentchange()'.
Previous patch made dirstate changes in a transaction scope "all or
nothing". Therefore, 'dirstateguard' is meaningless, if its scope is
as same as one of the related transaction.
Before this patch, "hg import" uses 'dirstateguard' always, but
transaction is also started if '--no-commit' isn't specified.
To avoid redundancy, this patch makes "hg import" use dirstateguard
only if transaction isn't started (= '--no-commit' is specified).
In this patch, 'if dsguard' can be examined safely, because 'dsguard'
is initialized (with None) before outermost 'try'.
As bundle1 does not support generaldelta, this would mean recomputing delta at
bundle time. This is similar to what we do for strip and shelve and was tracked
as issue4865.
We had some basic undocumented support for uncompressed bundle2 support. We now
have an official extensible syntax to specify both format type and compression
(eg: bzip2-v2).
In practice, this changeset introduce the 'v1' and 'v2' identifier to make it
possible to combine format and compression. The default format is still 'v1'.
We'll care about picking 'v1' or 'v2' in regard with general delta in the next
changesets.
We are going to introduce significant extensions of the bundle parsing code to
support creation of bundle2 through the bundle command. As an early step, we
extract the logic in its own function.
This used to stack trace because it raised a util.Abort which wasn't
handled in this block. We now handle it. Additionally, we error out
earlier instead of plodding on and showing the "log" entry of the
plain `hg help` output.
Add debugextensions command to help users debug their extension
problems. If there are no extensions command prints nothing,
otherwise it prints names of extension modules. If quiet or
verbose option is not specified it prints(after extensions name)
last version of mercurial in which given module was tested for
non internal modules or not tested with user mercurial version.
If verbose is specified it prints following information for every
extension: extension name, import source, testedwith and buglink
information.
Extensions are printed sorted by extension name.
The logic that decides where to update according to the active bookmark
location (when not on ".") was setting the rev to update to before we process
--date. This lead to --date processing aborting because of duplicated
specification.
We reorder the two pieces of code and add a test for this.
support combining -c and -e
previously -k was misdocumented:
* the first line didn't mention it
* the help half implied you could do help -k keyword topic
with these changes, -k just changes the search method
support -c and -e for -k searches
The update command is touching the repository and should lock it for
the length of its operations. Equally importantly, it should lock the
repository when it is writing bookmarks. It wasn't doing so until now,
leaving doors open for all kinds of drunk beaver parties.
This results in some minor tests changes, and the fixing of a couple
of bugs from race conditions.
Code does not receive any changes beside extra indentation.
Path instances now have a "pushloc" attribute that exposes the path
to be used for pushing. The "default-push" path is automatically
captured in the "pushloc" attribute of the "default" path.
Drop references to "default-push" and use the "pushloc" attribute
for looking up where to push to.
ui.path instances now collect most of the data used by commands.push().
Move away from ui.expandpath() and call ui.paths.getpath() to get a
path instance.
Some "pushing to" output was dropped as one test demonstrates. I believe
the dropped message was redundant with the error message and the change
to be acceptable.
On repositories with hundreds of thousands of files, hg
debugrebuilddirstate causes every dirstate entry to be marked lookup,
and the next hg status can take many minutes.
This adds a --minimal flag that allows us to only rebuild the parts of the
dirstate that are inconsistent. This follows two rules:
1) If a file is in the dirstate but not in the parent manifest, and it is not
marked 'add', it is busted and we should drop it.
2) If a file is not in the dirstate at all, but it is in the parent
manifest, it should be added to the dirstate and we need to mark it as
lookup.
This allows us to fix repositories where the dirstate doesn't match
the manifest much more quickly.
Tested by artificially adding bad dirstate entries (via code) for both cases
above.
Future patches will remove the old-style parser that happen to accept a
binary nodeid. A binary nodeid shouldn't be passed to scmutil.revrange()
because it is ambiguous. For example, bin('20' * 19 + '30') is valid binary
nodeid, but it can also be parsed as a revset expression, '0'.
The next patch will move the exceptional parsing of old-style ranges
to revset.tokenize(). This patch will allow us to see the result tree.
Note that the parsing result of '-a-b-c-' is incorrect at this changeset.
It will be fixed soon.
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'.
Because flush() is the function to write data buffered by show(ctx),
flush(ctx) is more consistent than flush(rev). This makes sure that
buffered header and hunk are always keyed by ctx.rev().
This patch will allow us to give an integer to the wdir while keeping
wctx.rev() -> None.
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.
For some time, bookmark can and should be moved in the transaction. This
changeset migrates the 'hg bookmarks' commands to use a transaction.
Tests regarding rollback and transaction hooks are impacted for
obvious reasons. Some have to be slightly updated to keep testing the
same things. Some can just be dropped because they do not make sense
anymore.
The previous scheme was:
1) lookup node for all pulled revision,
2) pull said node
3) lookup the node of the checkout target
4) update the repository there.
If the remote repo changes between (1) and (3), the resolved name will be
different and (3) crash. There is actually no need for a remote lookup during
(3), we could just set the value in (1). This prevent the race condition and
save a possible network roundtrip.
The editor launches without expanding the path with commits because the shell
does that for us.
If the path isn't an executable, the expanded path is displayed, which is
probably more useful than the unexpanded path. For example, in cmd.exe, '~'
expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in
MinGW.
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. Revert is one of these commands and the changes have
not been made for this release. Therefore, revert -i should be an experimental
feature for this release.
'hg revert -I foo' currently fails with
abort: no files or directories specified
(use --all to revert all files, or 'hg update 1' to update)
It doesn't seem intentional that -I/-X without other paths or
--all/--interactive should fail, and it doesn't seem that harmful to
allow it either, so let's just do that.
