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.
Since chmod isn't supported on Windows (or vfat), I'm importing a here-doc
instead (<<EOF ..).
Option --bypass on import of the here-doc is required on Windows (or vfat) to
bypass the working directory (see hg help import). Not using --bypass would
lose the mode changing bits.
I've had to insert a --bypass on the preexisting import call futher down in the
test, because importing a patch with --exact and mode changes will fail on
Windows (and vfat).
As the point of this test is not to test commit, I'm using the import
procedure for all platforms unconditionally, that is, I'm intentionally not
keeping the original sequence of hg and chmod calls for platforms that support
exec either, which saves us having to insert an #if exec ... #else ... #endif.
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.
The existing help only walked through an example.
Now we first explain the basic rules and then show an example.
The 'collections' example and description only cause confusion and is removed.
Bikeshedded by Patrick Mezard <patrick@mezard.eu>
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.
The new "diff" field lets you use the matching revset keyword to find revisions
that apply the same change as the selected revisions.
The match must be exact (i.e. same additions, same deletions, same modified
lines and same change context, same file renames and copies).
Two revisions matching their diff must also match their files. Thus, to match
the diff much faster we will always check that the 'files' match first, and only
then check that the 'diff' matches as well.
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
Timezone offsets of less than a minute is not shown but can cause displayed
dates to be before epoch start - and dates before epoch start is not shown
correctly on Windows (see also e68101a876a4).
These 'negative' dates could be considered undefined behaviour so we don't care
and swap the tests values for timestamp and timezone.
The test would occasionally fail because datesort don't have sub-second
granularity and thus can't sort commits made in the same second.
The test is made more stable by adding 1 second of sleep to make sure the bzr
commits are done with different timestamps.
Factor update code common to all callers of _addpath into _addpath.
By centralizing the update code here, it provides one place to put
updates to new data structures - in a future patch. It also removes
a few lines of duplicate code.
The adaption is partial, because "serve" is not yet officially supported in
tests on Windows.
The test passes on Windows with an experimental testbed that supports
hg serve in tests on Windows - except for some USERCACHE issues.
The added (glob)'s are needed because of backslash <-> shlash issues in paths.
