[PATCH 4 of 4] clfilter: fallback to unfiltered version when linkrev point to filtered history
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Thu Jan 3 17:37:23 CST 2013
On 3 janv. 2013, at 22:41, Kevin Bullock wrote:
> On Jan 1, 2013, at 7:36 PM, Pierre-Yves David wrote:
>
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
>> # Date 1356738018 -3600
>> # Node ID a397f42becefc44489d4d2cffb14ac1999aea375
>> # Parent d2f15a6470d3566b722379d48da8c88b26f398fd
>> clfilter: fallback to unfiltered version when linkrev point to filtered history
>> [...]
>> diff --git a/mercurial/context.py b/mercurial/context.py
>> --- a/mercurial/context.py
>> +++ b/mercurial/context.py
>> @@ -416,11 +416,30 @@ class filectx(object):
>> if fileid is not None:
>> self._fileid = fileid
>>
>> @propertycache
>> def _changectx(self):
>> - return changectx(self._repo, self._changeid)
>> + try:
>> + return changectx(self._repo, self._changeid)
>> + except error.RepoLookupError:
>> + # Linkrev may point to any revision in the repository. When the
>> + # repository is filtered this may lead to `filectx` trying to build
>> + # `changectx` for filtered revision. In such case we fallback to
>> + # creating `changectx` on the unfiltered version of the reposition.
>> + # This fallback should not be an issue because`changectx` from
>> + # `filectx` are not used in complexe operation that care about
>> + # filtering.
>> + #
>> + # This fallback is a cheap and dirty fix that prevent several
>> + # crash. It does not ensure the behavior is correct. However the
>> + # behavior was not correct before filtering either and "incorrect
>> + # behavior" is seen as better as "crash"
>> + #
>> + # Linkrevs have several serious troubles with filtering that are
>> + # complicated to solve. Proper handling of the issue here should be
>> + # considered when solving linkrev issue are on the table.
>> + return changectx(self._repo.unfiltered(), self._changeid)
>
> Won't this blow the stack if the linkrev isn't in the changelog? This would only happen on a corrupt repo, but it seems like an unnecessarily spectacular way to fail on a bad filelog.
No, it's an alternative call, not a recursive one.
When the second call fails re exception reach the caller as before.
--
Pierre-Yves
More information about the Mercurial-devel
mailing list