Obsolete markers wide-usage and propagation should be avoided by default until
the obsolete feature is more mature.
This changeset introduce the `_enable` variable and prevent the creation of
obsolete marker if the feature is set to `False` (the default).
More limitation comes in followup changesets.
Obsolete markers are now exchanged in smaller pieces that fit in a http header.
This changes is done to avoid 400 bad request error when exchanging obsolete
puskey over http.
The last key pushed is always hold by the "dump0" key to ensure an easy place to
hook for people who need it.
Previously, browsing to http://serv/diff would generate an internal
server error due to the file and node parameters being missing.
The same error also occurred for filelog, comparison and annotate.
Some help topics use "-" for the top level underlining section mark,
but "-" is used also for the top level categorization in generated
documents: "hg.1.html", for example.
So, TOC in such documents contain "sections in each topics", too.
This patch changes underlining section mark in some help topics to
unify section level in generated documents.
After this patching, levels of each section marks are:
level0
""""""
level1
======
level2
------
level3
......
level4
######
And use of section markers in each documents are:
- mercurial/help/*.txt can use level1 or more
(now these use level1 and level2)
- help for core commands can use level2 or more
(now these use no section marker)
- descriptions of extensions can use level2 or more
(now hgext/acl uses level2)
- help for commands defined in extension can use level4 or more
(now "convert" of hgext/convert uses level4)
"Level0" is used as top level categorization only in "doc/hg.1.txt"
and the intermediate file generated by "doc/gendoc.py", so end users
don't see it in "hg help" outoput and so on.
If you've got this graph:
0-1-2
\
3
and 3 is checked out, 2 is bookmarked with "broken", and you do "hg
strip 2", the bookmark will move to 3, not 1. That's always struck me
as a bug.
This change makes bookmarks move to the tipmost ancestor of
the stripped set rather than the currently-checked-out revision, which
is what I always expected should happen.
This change adds `obsstore` to the list of files copied by local clone,
until now changesets were copied without their obsolete markers.
Note: extinct changesets were and are still included by such clones to
enable hardlinking. There is no obvious reason to prevent their exchange
here.
Rebased by Patrick Mezard <patrick@mezard.eu>
Before this change, push would incorrectly fast-path the bundle
generation when extinct changesets are involved, because they are not
added to outgoing.excluded. The reason to do so are related to
outgoing.excluded being assumed to contain only secret changesets by
scmutil.nochangesfound(), when displaying warnings like:
changes found (ignored 9 secret changesets)
Still, outgoing.excluded seems like a good API to report the extinct
changesets instead of dedicated code and nothing in the docstring
indicates it to be bound to secret changesets. This patch adds extinct
changesets to outgoing.excluded and fixes scmutil.nochangesfound() to
filter the excluded node list.
Original version and test by Pierre-Yves.David@ens-lyon.org
This copies the performance hack from encoding.lower (e7a5733d533f).
The case-folding logic that kicks in on case-insensitive filesystems
hits encoding.upper hard: with a repository with 75k files, the
timings went from
hg perfstatus
! wall 3.156000 comb 3.156250 user 1.625000 sys 1.531250 (best of 3)
to
hg perfstatus
! wall 2.390000 comb 2.390625 user 1.078125 sys 1.312500 (best of 5)
This is a 24% decrease. For comparison, Mercurial 2.0 gives:
hg perfstatus
! wall 2.172000 comb 2.171875 user 0.984375 sys 1.187500 (best of 5)
so we're only 10% slower than before we added the extra case-folding
logic.
The same decrease is seen when executing 'hg status' as normal, where
we go from:
hg status --time
time: real 4.322 secs (user 2.219+0.000 sys 2.094+0.000)
to
hg status --time
time: real 3.307 secs (user 1.750+0.000 sys 1.547+0.000)
When calling encode on a str, the string is first decoded using the
default encoding and then encoded. So
s.encode('ascii') == s.decode().encode('ascii')
We don't care about the encode step here -- we're just after the
UnicodeDecodeError raised by decode if it finds a non-ASCII character.
This way is also marginally faster since it saves the construction of
the extra str object.
The "worst" extension still is the one tested with the lowest tested version
below the current version of Mercurial, but if an extension with was only
tested with newer versions, it is considered a candidate for a bad extension,
too. In this case extensions which have been tested with higher versions of
Mercurial are considered better. This allows finding the oldest extension if
ct can't be calculated correctly and therefore defaults to an empty tuple, and
it involves less changes to the comparison logic during the current code
freeze.
Changeset 8c1e21a3407c caused this when the "from win32 import *" line
was replaced with explicit import statements: the wildcard import was
at the bottom of the file and so windows.termwidth was overwritten by
win32.termwidth as indented, but the new explicit import statements
were at the top and so win32.termwidth got lost.
With the switch to ctypes, win32 can always be imported and so the
fallback termwidth in windows is no longer needed.
If we push some successors they will likely create a new head on
remote. However as the obsoleted head will disappear after the push we
are not really increasing the number of heads.
There is several case which will lead to extra being actually pushed. But this
first changeset aims to be simple. See the inline comment for details.
Without this change, you need to push --force every time you want to
push a newer version which is very error prone.
The remote side still display +n heads on unbundle because it does not have the
obsolete marker at unbundle time.
This function yield every nodes which succeed to a group of nodes.
The first user will be checkheads who need to know if we push successors for
remote extra heads.
The checkheads function is far too complicated. This extract help to explicite
what part of the preprocessing are reused by the actual check.
This the first step toward a wider refactoring.
The repo.hiddenrevs set is updated with all extinct() changesets which aren't
descendants of either:
- the current working copy,
- a bookmark,
- a tag.
This set is always accessed through the repo for now. Having this set
carried by the changelog make it complicated to:
- initialize it, computing hidden set may involve revset call
- lazy compute it, (1) only the changelog can detect someone access it,
(2) only the repo have enought knowledge to compute it.
In later version I expect he changelog to apply filtering itself and the set to
be carried by changelog again.
Extinct changesets are excluded from all exchange operations. This is a silent
exclusion because the user should not need to be aware of them.
There is no reason to strongly enforce this exclusion except implementation
simplicity. User should be able to explicitly request an extinct changeset in
the future.
They were previously inside the mercurial.phases module, but obsolete
logic will need them to exclude `extinct` changesets from pull and
push.
The proper and planned way to implement such filtering is still to apply a
changelog level filtering. But we are far to late in the cycle to implement and
push such a critical piece of code (changelog filtering). With Matt Mackall
approval I'm extending this quick and dirty mechanism for obsolete purpose.
Changelog level filtering should come during the next release cycle.
