This speeds up status on a largefiles repo by synchronizing the largefiles dirstate to the
largefile's mtime upon update, preventing the files from coming back as "unsure" later,
requiring a check of the SHA1 sum.
Before this patch, MQ checks each subrepo synchronizations against the
working directory context, so ".hgsubstate" updating is not imported
into MQ revision correctly in cases below:
- qrefresh when current ".hgsubstate" is already synchronized with
each subrepos: you can reproduce this easily by just twice or more
qrefresh invocations
- qnew just after rollback of commit which updates ".hgsubstate"
This patch resolves this by checking subrepo states against:
- the parent of "qtop" for qrefresh, or
- the parent of working context otherwise
Even though the committed revision contains diff of ".hgsubstate", the
patch file created by qrefresh doesn't contain it, because:
- ".hgsubstate" is not listed up as one of target files of the patch
for reasons below, so diff of ".hgsubstate" is not imported into
patch file
- status of ".hgsubstate" in working directory is usually "clean"
- ".hgsubstate" is not specified explicitly by users
- the patch file is created before commit processing which updates
or creates ".hgsubstate" automatically, so there is no diff for it
at that time
This patch resolves this problem by:
- putting ".hgsubstate" into target list of the patch, if needed:
this allows "patch.diff()" to import diff of ".hgsubstate" into
patch file.
- creating the patch file after commit processing:
this updates ".hgsubstate" before "patch.diff()" invocation.
For the former fixing, this patch introduces "putsubstate2changes()"
to share same implementation with qnew. This is invoked only once per
qnew/qrefresh at most, so there is less performance impact.
This patch also omits "match" argument for "patch.diff()" invocation,
because "patch.diff()" ignores "match" if "changes" is specified.
If ".hgsubstate" is already listed up as one of commit targets, qnew
put diff of ".hgsubstate" twice into the patch file stored under
".hg/patches".
It causes rejections at applying such patches.
Other than the case like in added test script, this can also occur
when qnew is executed just after rolling back the committing updated
".hgsubstate".
This patch checks whether ".hgsubstate" is already listed up as one of
commit targets, and put it into the appropriate list only if it is not
listed up yet.
This implements a part of issue 3386. It batches the request for the status of
all largefiles in the revisions that are about to be pushed into a single
request, instead of doing N separate requests.
In a real world test case, this change was verified to save 1,116 round-trips to
the server. It only requires a client-side change; it is backwards-compatible
with an older version of the server.
Most uses of templates requires a trailing newline to get vertical output.
Graphlog with a template without trailing newline did however not just create
horisontal output like other commands would but truncated the output at the
last \n. Template values without any \n were ignored completely.
Graphlog will now only eat one trailing newline before it lets the flow of the
graph add the necessary vertical space.
Changeset detected as obsolete will be displayed as "x" instead of 'o':
o new rewritten changeset
|
| x old obsolete changeset
|/
|
o base
This will be useful even when some obsolete changeset will be "hidden" because
not all obsolete changeset can be hidden. If an obsolete changeset have
non-obsolete descendant we can't simply hide it. And having a clear visual hint
that the changeset is obsolete is useful.
The main reason to make this minor change right now is to:
1) introduce an officiel user of the `ctx.obsolete()` method that will detect
breakage earlier than third party code (mutable, hgview)
2) Do not display any vocabulary related to obsolete. Such vocabulary will
require discussion.
Add a match object to subrepo.archive(). This will allow the -X and -I
options to be honored inside subrepos when archiving. They formerly
only affect the top level repo.
When running convert with a filemap, merge parents which are ancestors
of other parents are ignored. This is hardly a problem when parents
belong to the same branch, but the result could be confusing when named
branches are involved. With:
-o-a1-a2-a3... <- A
\ \
b1-b2-b3...-m- <- B
If all b* revisions are discarded, it is useful to preserve 'm' even if
it is empty after filtering to record the branch switch.
This patch makes filemap preserve "ancestor parents" if there is no
"non-ancestor parent" on the same branch than the merge revision.
Remarks:
- I am not completely convinced by the reasons given above and those
detailed by Matt in this thread:
http://selenic.com/pipermail/mercurial-devel/2012-May/040627.html
The properties we try to preserve are not clearly defined. That said,
I know this patch already helped someone on IRC and the tests output
look reasonable.
- This is a new version of the original "convert: filemap must preserve
fast-forward merges" patch. It has exactly the same output for 2
parents merges, the additional complexity is here to handle more than
two parents.
mq wraps all commands that are not in commands.norepo, which is now performed in
this second phase of the extensions setup process. This goes against the
current best practices on the wiki [1] as far as where command wrapping is
performed, but follows it regarding where global options are injected.
mq needs to be the first layer called when command dispatching in order to
consistently retarget to the patch repo, regardless of the load order of the
extensions. This means being the last to wrap the command table. Previously,
'hg <extdiff> --mq' would diff the main repo unless mq was enabled after
extdiff.
[1] http://mercurial.selenic.com/wiki/WritingExtensions
When you rebased with a currently active bookmark, that bookmark would
always point at the new tip, regardless of what revision it pointed at
before the rebase.
All bookmarks will now point at the equivalent post-rebase commit.
However, the currently active bookmark will cease to be active unless
it points at the new tip post-rebase. Rebase will always leave the
new tip as the working copy parent, which is incompatible with having
an active bookmark that points at some other revision. The common
case should be that the active bookmark will point at the new tip
post-rebase.
'hg debugsvnlog' failed with a crash when using the uninitialized transport in
get_log_child if the import of the svn libraries had failed.
'convert' should never get as far as launching 'hg debugsvnlog' if the svn
libraries are missing, but by launching a subprocess there is risk that the
environment is mangled so the second import fails.
It is in principle also possible to launch the command manually.
Subversion can handle ':' quoted as '%3A' but urllib.url2pathname can't and
Mercurial thus rejected some valid subversions URLs.
This particular case will now be handled by some preprocessing before handing
it over to urllib.url2pathname.
This is tested by a0c992a723f9 when test-convert-svn-source.t and
test-convert-svn-move.t can be run on Windows.
Calling propset/propdel with subversion 1.6 on FAT gave
abort: svn exited with status 256
and made test-convert-hg-svn.t and test-convert-svn-sink.t fail. 1.7 worked.
This is a rework of 5ba59c098f03 but ignores the executable bit when it isn't
supported instead of using an approximation.
The previous error message had two issues: The first issue was that it
wasn't, in fact, an error but a warning, even though it described a
fatal error condition preventing the successful completion of the
command. The second was that it didn't mention the immutable
changesets, leaving the user guessing at the true cause of the error.
The main downside to this change is that we now get an 'abort: can't
abort...' message which technically contradicts itself. In this case,
I blame that on the two uses we have for the word; if it weren't for
backwards compatibility, we could make util.Abort print out 'error:
<whatever>'.
The "!" prefix allows you to prevent anyone except a given user or group to push
changesets in a given branch or path.
This patch enables a use case suggested by a user (Julien Bonnet):
There's a branch that only a given user (or group) should be able to push to,
and you don't want to restrict access to any other branch that may be created.
With the "!" prefix, you simply deny access to "!givenuser" (or "!@givengroup").
