[PATCH STABLE] bookmarks: use try/except for accessing a node

Matt Mackall mpm at selenic.com
Wed Mar 19 13:12:13 CDT 2014


On Tue, 2014-03-18 at 19:49 -0500, Sean Farley wrote:
> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
> 
> > On 03/18/2014 05:23 PM, Sean Farley wrote:
> >> # HG changeset patch
> >> # User Sean Farley <sean.michael.farley at gmail.com>
> >> # Date 1395182192 18000
> >> #      Tue Mar 18 17:36:32 2014 -0500
> >> # Branch stable
> >> # Node ID 8d3d12401c38524417f1151b817fd210645a0602
> >> # Parent  03774a2b6991b451bde7095238fde9ce98380d28
> >> bookmarks: use try/except for accessing a node
> >>
> >> Previously, in bookmarks.compare a changeset node would be tested via 'node in
> >> repo' but this is tricky. A value of 'True' could be returned even if the node
> >> is hidden and accessing it will throw a 'RepoLookupError'. This happens when a
> >> remote bookmark points to changeset that has been obsoleted locally. Therefore,
> >> we wrap the block in a try/except which handles catching the error.
> >
> > 1. `<node> in repo` should not return True if the revision is filtered.
> >     Consider fixing this instead.
> >
> > 2. During bookmark pulling, a bookmark should cleanly apply on a
> >     filtered changeset making it visible again.
> >     Consider fixing this instead.
> >
> > 3. There is multiple example of test using public changeset in
> >     test-obsolete.t You should be able to build a test case from that.
> 
> This is a two-line fix for the craziness that is repoview.

Except it doesn't actually appear to be a fix. It just masks a symptom
of an underlying problem.

This is generally worse than doing nothing, because hiding the symptoms
makes it less likely that the underlying problem will be addressed. 

-- 
Mathematics is the supreme nostalgia of our time.





More information about the Mercurial-devel mailing list