Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Jan 2013 23:41:48 +0100] rev 18447
rebase: properly handle unrebased revision between rebased one
With rebase taking multiple roots it is possible to have revision in the "rebase
domain" not rebased themself. We do not want rebased revision above them to be
detached. We want such revision to be rebased on the nearest rebased ancestors.
This allows to preserve the topology of the rebase set as much a possible
To achieve this we introduce a new state `revignored` which informs
`defineparents` of the situation.
The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Jan 2013 23:21:32 +0100] rev 18446
rebase: lose the comparison to `nullmerge`
For a proper behavior of the `--rev` revision we will need another possible
state for revision ignored by rebase. We alter the comparison to `nullmerge`
to match this future lower state too.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 18 Jan 2013 23:43:32 +0100] rev 18445
repoview: cache filtered changelog
Creating a new changelog object for each access is costly and prevents efficient
caching changelog side. This introduced a x5 performance regression in log
because chunk read from disk were never reused. We were jumping from about 100
disk read to about 20 000.
This changeset introduce a simple cache mechanism that help the last changelog
object created by a repoview. The changelog is reused until the changelog or the
filtering changes.
The cache invalidation is much more complicated than it should be. But MQ test
show a strange cache desync. I was unable to track down the source of this
desync in descent time so I'm not sure if the issue is in MQ or core. However
given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route
that makes the cache mechanism safer.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Jan 2013 14:15:32 +0100] rev 18444
rebase: do not invent successor to skipped changeset
When rebase results in an empty a changeset it is "skipped" and no related
changeset is created at all. When we added obsolescence support to rebase (in
fc2a6114f0a0) it seemed a good idea to use its parent successor as the
successors for such dropped changesets. (see old version of the altered test).
This option was chosen because it seems a good way to hint about were the
dropped changeset "intended" to be. Such hint would have been used by automatic
evolution mechanism to rebase potential unstable children.
However, field testing of this version are not conclusive. It very often leads
to the creation of (totally unfounded) evolution divergence. This changeset
changes this behavior and mark skipped changesets as pruned (obsolete without
successors). This prevents the issue and seems semantically better probably a
win for obsolescence reading tool.
See example bellow for details:
User Babar has five changesets of interest:
- O, its current base of development.
- U, the new upstream
- A and C, some development changesets
- B another development changeset independent from A
O - A - B - C
\
U
Babar decides that B is more critical than the A and C and rebase it first
$ hg rebase --rev B --dest U
B is now obsolete (in lower case bellow). Rebase result, B', is its
successors.(note, C is unstable)
O - A - b - C
\
U - B'
Babar is now done with B', and want to rebase the rest of its history:
$ hg rebase --source A --dest B'
hg rebase process A, B and C. B is skipped as all its changes are already contained
in B'.
O - U - B' - A' - C'
Babar have the expected result graph wise, obsolescence marker are as follow:
B -> B' (from first rebase)
A -> A' (from second rebase)
C -> C' (from second rebase)
B -> ?? (from second rebase)
Before this changeset, the last marker is `B -> A'`. This cause two issues:
- This is semantically wrong. B have nothing to do with A'
- B has now two successors sets: (B',) and (A',). We detect a divergent
rewriting. The B' and A' are reported as "divergent" to Babar, confusion
ensues. In addition such divergent situation (divergent changeset are children
to each other) is tricky to solve.
With this changeset the last marker is `B -> ΓΈ`:
- This is semantically better.
- B has a single successors set (B',)
This scenario is added to the tests suite.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 17 Jan 2013 17:51:30 +0100] rev 18443
repoview: protect `base` computation from weird phase root
If for some reason the phase roots contains nullid, the set of filtered revs
will contains -1. That confuse Mercurial a lot. In particular this corrupt the
branchcache.
Standard code path does not result in nullid phase root. It can only result from
altered `.hg/store/phaseroots` or buggy extension. However better safe than
sorry.
Siddharth Agarwal <sid0@fb.com> [Fri, 18 Jan 2013 15:55:16 -0800] rev 18442
posix: don't compare atime when determining if a file has changed
A file's atime might change even if the file itself doesn't change. This might
cause us to invalidate caches more often than necessary.
Before this change, hg add often resulted in the dirstate being parsed twice
on systems that track atime. After this change, it is only parsed once. For a
repository with over 180,000 files, this speeds up hg add from 1.2 seconds to
1.0.
Augie Fackler <raf@durin42.com> [Fri, 05 Oct 2012 18:10:56 -0500] rev 18441
hg: replace DirCleanup class with normal try/finally use
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:21:03 +0100] rev 18440
histedit: proper phase conservation (issue3724)
Before this changeset, histedit created all new changesets according
phases.new-commit option without any regards for the phases of the original
changesets.
This changeset fix that using the phase of rewritten changeset to decide the
phase of the resulting changeset. In case of reordering or folding, we keep
secret item secret as it seems the safer path.
temporary commit creation are not affected. They are head only and stripped at
the end of the histedit.
As for the resolution of issue3681 (obsolescence cycle prevention), we do not
handle changesets created by edit command.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:19:56 +0100] rev 18439
test-histedit: reorder phases test and prepare for more
We are going to add a lot regarding phase of test while fixing issue3724.
This movement allows to put them after this first phase test.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:17:36 +0100] rev 18438
test-histedit: fix instability creation test
The current test does not rewrite anything and therefor does not create any
instability.
We also clean up the repo state after the test. This required the rebase
extension.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:14:22 +0100] rev 18437
histedit: record histedit source (issue3681)
Have histedit record the hex of the original changeset as already done by:
- graft
- commit --amend
- rebase
My main motivation for adding this is to prevent the creation of obsolescence cycle
(see issue3681).
Note that commit created during edit are not affected yet.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 19:11:06 +0100] rev 18436
histedit: factor most commit creation in a function
Later commits add two important items to histedit:
- Obsolescence cycle prevention
- Proper phase conservation
Those logics must be applied to all simple operations (pick, edit, mess) and
will require verbose code.
So we introduce a new function that will provide an entry point for this new.
logic.
The function build a closure to have a clear distinction between commit
arguments and data provided to the function to fulfil its logic.
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:37 -0800] rev 18435
store: switch to C-based hashed path encoding
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:36 -0800] rev 18434
pathencode: implement both basic and hashed encoding in C
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:36 -0800] rev 18433
pathencode: implement hashed encoding in C
This will be used by an upcoming patch.
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:35 -0800] rev 18432
pathencode: implement the "mangling" part of hashed encoding in C
This will be used by an upcoming patch.
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:34 -0800] rev 18431
pathencode: add a SHA-1 hash function
This will be used by an upcoming patch.
This calls out to the Python hash implementation.
An earlier version of this function implemented SHA-1 directly, but
the amount of extra code didn't seem like a good tradeoff compared
to the small big-picture increase in performance (long paths are
uncommon).
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 13:09:33 -0800] rev 18430
store: implement lowerencode in C
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 15 Jan 2013 22:34:56 +0100] rev 18429
hgweb: run with "served" filter
This changeset enable the "served" filter on all repo used by hgweb.
Hgweb misbehave in a lot of when filtering changeset are present but I do not
expect normal people to have secret or obsolete changeset on they server.
Misbehavior will be gradually fixed later.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 14:22:43 +0100] rev 18428
hgweb: walk the graph through the changelog
This is necessary to enforce filtering. The result is a bit buggy (may provide
less changeset than expected, but it will stop crashing on filtered revision
access.
Note that changelog.revs can not represents empty iteration like xrange did. So
we have to explicitly prevent call when there is nothing to do.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 11 Jan 2013 01:08:00 +0100] rev 18427
hgweb: use changelog for iteration
Iterating through changelog is necessary to enforce filtering.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 14:19:28 +0100] rev 18426
hgweb: ignore filtered revision in revnav
This changeset checks that a revision is known before adding it to the
navigation.
This will prevent traceback on filtered repository. This changeset result in an
incorrect behaviors, Navigation link may be dropped without any replacement.
However this bad navigation generation is much better than a crash
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 19:29:48 +0100] rev 18425
hgweb: generate revnav in two phase
We first generate revision to link. Then we dispatch them in before, after list.
This will help filtering of unknown revision.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 17 Jan 2013 00:35:01 +0100] rev 18424
rebase: support multiple roots for rebaseset
We have all the necessary mechanism to rebase a set with multiple roots, we only
needed a proper handling of this case we preparing and concluding the rebase.
This changeset des that.
Rebase set with multiple root allows some awesome usage of rebase like:
- rebase all your draft on lastest upstream
hg rebase --dest @ --rev 'draft()'
- exclusion of specific changeset during rebase
hg rebase --rev '42:: - author(Babar)'
- rebase a set of revision were multiple roots are later merged
hg rebase --rev '(18+42)::'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 05:21:11 +0100] rev 18423
clfilter: stronger detection of filtered changeset in changectx.__init__
We previously let some IndexError spill out of this function.
A new tests is added to check the command that spotted the error.
Sune Foldager <cryo@cyanite.org> [Tue, 11 Dec 2012 20:13:21 +0100] rev 18422
validate: check for spurious incoming filelog entries
Accepting those will lead to "mild corruption", correctly reported as
an error by hg verify, but often not a problem in practice.
Enabled when server.validate is switched on.
Johannes Schlatow <johannes@schlatow.name> [Thu, 17 Jan 2013 01:06:00 +0100] rev 18421
zsh_completion: add descriptive branch names to head revisions
Johannes Schlatow <johannes@schlatow.name> [Thu, 17 Jan 2013 00:54:49 +0100] rev 18420
zsh_completion: add completion of branch names
Johannes Schlatow <johannes@schlatow.name> [Thu, 17 Jan 2013 01:55:50 +0100] rev 18419
zsh_completion: fix issue with overlong branch/tag names
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:52:56 +0100] rev 18418
bundlerepo: remove old style check of file names
The old check is no longer needed:
The checked paths will be passed on to filelog.__init__ which will prefix the
path with 'data/'. A leading '/' will thus not do any harm.
And: The paths will be used by an opener which will use a pathauditor.
And finally: The old check did not consider Windows paths and was thus
insufficient.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18417
bundlerepo: use revlog._checkhash
The error message will mention datafile instead of indexfile.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18416
bundlerepo: store validated deltabase rev in basemap instead of node
This avoids some lookups and aligns bundlerepo more with what revlog do.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18415
bundlerepo: use rev instead of node for iteration in revision()
Avoids some lookups and avoids using rev while iterating.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18414
bundlerepo: inline inbundle()
It didn't make it faster, it didn't make the code smaller, it didn't make the
code simpler.
-1 is never in basemap.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18413
bundlerepo: drop bundlebase wrapper function for basemap
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:41 +0100] rev 18412
bundlerepo: remove unused disktiprev attribute
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:34 +0100] rev 18411
bundlerepo: improve performance for bundle() revset expression
Create the set of revision numbers directly instead of creating a list of nodes
first.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:32 +0100] rev 18410
bundlerepo: fix outdated comment
Comment was made invalid by 01ee43dda681.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 13:18:22 +0100] rev 18409
hgweb: pass repo object to revnav construction
For compatibility with changelog filtering we need access to the changelog, a
simple nodefunc is not sufficient, only the changelog and repo have access the
filteredrevs information.
For the filerevnav version, we use an unfiltered changelog. Linkrev is currently
broken with filtering and we need some failsafe to prevent traceback. This is
the same approach as the one used in 518c1403838f. The use of
filectx.changectx() allowed the previous code to use the 518c1403838f hack.
This changeset may result in an incorrect behaviors, Navigation
link may point to missing revision. However this bad navigation
generation is much better than a plain crash
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 14 Jan 2013 16:55:48 +0100] rev 18408
hgweb: introduction a filerevnav subclass
It'll be use to implement the file specific behavior.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 19:09:32 +0100] rev 18407
hgweb: simplify addition of "(0) navigation entry"
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 14 Jan 2013 16:30:06 +0100] rev 18406
hgweb: simplify the handling of empty repo
This abstraction have two advantages:
- If the revlog is empty, None of the code bellow is relevant,
early returns seems a win.
- Abtraction of the 'emptiness' check will help later when we stop relying on
nodefunc.
A bonus, with filtering, a non-empty revlog may not have '0' revision
accessible. It'll be easier to handle with the emptiness test in a dedicated
function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:54:50 +0100] rev 18405
hgweb: move hex creation into an object method
This is clearer and allow later overwrite.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:59:37 +0100] rev 18404
hgweb: pass nodefunc to the revnav object
The issue between hgweb and filtering lay in this function. Moving it into the
object itself helps to abstract the erroneous bit.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 15 Jan 2013 21:17:18 +0100] rev 18403
hgweb: move revnavgen into an object
For later compatibility with changelog filtering some part of the navigation
generation logic will be altered. Those altered part will be different when in
the changelog case and in the filelog case. Moving this into an object will
allow to use inheritance to override just the part of the logic we need.
The aimed logic are for example:
- generation of revision 'hex' (different logic for changelog and filelog)
- revlog emptyness test
- fetching of the first revision of a revlog (may not be 0)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 12:51:24 +0100] rev 18402
hgweb: `limit` argument is actually `latestonly` renames and enforce
The `limit` argument of several generator have only two possible values in
practice: 0 and 1. We rename this parameter to `latestonly` and simplify it's
handling.
The simplification allows us to save fetching of data that we are sure to not
consume.
Having a function minimal function perimeter will helps future refactoring.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 11:39:22 -0600] rev 18401
hgweb: add test regarding filtering and hgweb
Since 4d1671b39168 hgweb is broken with filtering. This changeset add test that
should pass once it is fixed. Test currently broken are commented and will be
uncommented by changeset that fix them.
The filelog test is currently passing because we already have some hack in core
regarding filelog (see 518c1403838f).
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 14:26:19 +0100] rev 18400
get-with-headers: add a --headeronly switch
In some case we do not care about the actual rendering.
Kevin Bullock <kbullock@ringworld.org> [Tue, 15 Jan 2013 22:08:47 -0600] rev 18399
tests: more comment cleanup related to obsolescence
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 00:46:29 +0100] rev 18398
test: fix in-test comments related to obsolescence
The `ui.prevent-unstable` option never made it into core. It always behaves
this way when obsolescence feature is enabled.
See changesets c5bd753c5bc6, bacf55bd8f90 and 0f5a0a2073a8 for details.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 00:12:01 +0100] rev 18397
stream_in: write the remote branchcache for a usage as wide as possible
Writing cache for unfiltered repo only is barely useful, Most repo user are now
at least use the `hidden` filter. This changeset now assigns the remote cache
for a filter as low as possible for a wider reuse as possible.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 15 Jan 2013 23:33:07 +0100] rev 18396
destroyed: update `unserved` branchcache instead
Before this changesets the `destroyed` function updated the branchcache for
unfiltered repository. As seen in a previous changeset, Read only repo does
not cares about the unfiltered repo. We now update it for `unserved`.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 00:09:26 +0100] rev 18395
destroyed: drop complex branchcache rebuilt logic
The strip code used a trick to lower the cost of branchcache update after a
strip. However is less necessary since we have branchcache collaboration.
Invalid branchcache are likely to be cheaply rebuilt again a near subset of the
repo.
Moreover, this trick would need update to be relevant in the now filtered
repository world. It currently update the unfiltered branchcache that few people
cares about. Make it smarter on that aspect would need complexes update of the
calling logic
So this mechanism is:
- Arguably needed,
- Currently irrelevant,
- Hard to update
and I'm dropping it.
We now update the branchcache in all case by courtesy of the read only reader.
This changeset have a few expected impact on the testsuite are different cache
are updated.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 00:08:08 +0100] rev 18394
branchmap: update cache of 'unserved' filter on new changesets
The `commitctx` and `addchangegroup` methods of repo upgrade branchcache after
completion. This behavior aims to keep the branchcache in sync for read only
process as hgweb. See ee317dbfb9d0 for details.
Since changelog filtering is used, those calls only update the cache for unfiltered repo.
One of no interest for typical read only process like hgweb.
Note: By chance in basic case, `repo.unfiltered() == repo.filtered('unserved')`
This changesets have the "unserved" cache updated instead. I think this is the
only cache that matter for hgweb.
We could imagine updating all possible branchcaches instead but:
- I'm not sure it would have any benefit impact. It may even increase the odd of
all cache being invalidated.
- This is more complicated change.
So I'm going for updating a single cache only which is already better that
updating a cache nobody cares about.
This changeset have a few expected impact on the testsuite are different cache
are updated.
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 02:01:11 +0100] rev 18393
tests: make test-hgweb.t output stable
Instability introduced in combination of a4d7fd7ad1f7 and e389a25e7e60.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:52:17 +0100] rev 18392
hgweb: ensure _navseq yield strictly increasing numbers
This is not hard and allows to drop hack in the customer code.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:47:48 +0100] rev 18391
hgweb: better names for _navseq arguments
The old names were misleading.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:44:26 +0100] rev 18390
hgweb: drop recursivity in _navseq
This is totally not needed.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 15 Jan 2013 12:11:18 +0100] rev 18389
hgweb: move the `seq` function out of the revnavgen scope
There is not reason for it to be a in there. And this function could use a major
reworks.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 14 Jan 2013 16:52:35 +0100] rev 18388
hgweb: simplify return value creation in for navgen
We now have access to better syntax allowing a clearer version.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:55:50 +0100] rev 18387
hgweb: do not access first changeset with a string
There is not reason not to use an int
Mads Kiilerich <madski@unity3d.com> [Tue, 15 Jan 2013 23:30:10 +0100] rev 18386
refactoring: use unlinkpath with ignoremissing
Mads Kiilerich <madski@unity3d.com> [Tue, 15 Jan 2013 23:30:10 +0100] rev 18385
docs: "deprecate" checkchanged and checkconflicts in merge-tool configuration
These settings were replaced by check=changed and check=conflicts in
a912f26777d3. There is no reason to announce two different ways to achieve the
same. The old way should be kept but not announced.
Mads Kiilerich <madski@unity3d.com> [Tue, 15 Jan 2013 23:30:10 +0100] rev 18384
tests: run with PYTHONHASHSEED=random
Python set and dict iteration order is in principle undefined but usually
'quite stable'. Setting PYTHONHASHSEED=random will make the iteration order
more random in Python 2.6.8 and 2.7.3 and where it has been backported. This
can thus help spot dependencies on undefined behaviour and prevent future
problems.