[PATCH 4 of 4] clfilter: fallback to unfiltered version when linkrev point to filtered history

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Jan 3 15:41:49 CST 2013


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.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list