Mercurial > hg
view hgweb.cgi @ 27319:b64b6fdc5c9b
discovery: properly filter changeset in 'peer.known' (issue4982)
The 'peer.known' call (handled at the repository level) was applying its own
manual filtering (looking at phases) instead of relying on the repoview
mechanism. This led to the discovery finding more "common" node that
'getbundle' was willing to recognised. From there, bad things happen, issue4982
is a symptom of it. While situations like described in issue4982 can still
happen because of race conditions, fixing 'peer.known' is important for
consistency in all cases.
We update the code to use 'repoview' filtering. This lead to small changes in
the tests for exchanging obsolescence marker because the discovery yields
different results.
The test affected in 'test-obsolete-changeset-exchange.t' is a test for
issue4982 getting back to its expected state.
author | Pierre-Yves David <pierre-yves.david@fb.com> |
---|---|
date | Wed, 02 Dec 2015 16:12:15 -0800 |
parents | 4b0fc75f9403 |
children | 47ef023d0165 |
line wrap: on
line source
#!/usr/bin/env python # # An example hgweb CGI script, edit as necessary # See also https://mercurial-scm.org/wiki/PublishingRepositories # Path to repo or hgweb config to serve (see 'hg help hgweb') config = "/path/to/repo/or/config" # Uncomment and adjust if Mercurial is not installed system-wide # (consult "installed modules" path from 'hg debuginstall'): #import sys; sys.path.insert(0, "/path/to/python/lib") # Uncomment to send python tracebacks to the browser if an error occurs: #import cgitb; cgitb.enable() from mercurial import demandimport; demandimport.enable() from mercurial.hgweb import hgweb, wsgicgi application = hgweb(config) wsgicgi.launch(application)