[PATCH V4] hgweb: don't attempt to show hidden bookmarks (issue3774)

Kevin Bullock kbullock+mercurial at ringworld.org
Sat Jan 26 16:08:34 CST 2013


On 26 Jan 2013, at 3:10 PM, Idan Kamara wrote:

> On Sat, Jan 26, 2013 at 8:31 PM, Kevin Bullock <kbullock+mercurial at ringworld.org> wrote:
> >
> > # HG changeset patch
> > # User Kevin Bullock <kbullock at ringworld.org>
> > # Date 1359135834 21600
> > # Branch stable
> > # Node ID 0af7b5dc492f6573cec334b2ba0c7cebc2320b9c
> > # Parent  010d6d3fcfee422f4dd458321c6f540954548d7e
> > hgweb: don't attempt to show hidden bookmarks (issue3774)
> >
> > localrepository._bookmarks is unfiltered, but hgweb gets a filtered
> > repo. This fixes the resulting traceback on the 'bookmarks' page.
> 
> Isn't the problem a little bit deeper than removing the
> filtered bookmarks here? Every other place that will look
> at repo._bookmarks will have to do the same check.

Yes.

> Perhaps repoview.__init__ needs to call something that
> will cause repo._bookmarks to reconstruct itself (along
> with other objects that are based on possibly filtered
> csets), which will make those bookmarks not show up in
> the first place (repo.invalidatecaches seems like a good
> candidate but that requires some extra work).

That might work, although I'm not sure of the implications of having a filtered bmstore when performing operations on an unfiltered repo. The alternative would be to have *two* bmstore objects, just like we have two changelog objects, in the presence of a filtered repo: one attached to the repoview, and one attached to the unfiltered repo. But there again I'm not sure what the consequences of that are.

I suspect that such an undertaking is too much for the freeze, but we'll need to look at this (and other @repofilecache related issues) soon.

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



More information about the Mercurial-devel mailing list