<div dir="ltr">On Mon, Sep 24, 2012 at 1:08 AM, Pierre-Yves David <<a href="mailto:pierre-yves.david@ens-lyon.org">pierre-yves.david@ens-lyon.org</a>> wrote:<br>><br>><br>> On 20 sept. 2012, at 19:51, Idan Kamara wrote:<br>
><br>> > On Thu, Sep 20, 2012 at 8:12 PM, <<a href="mailto:pierre-yves.david@logilab.fr">pierre-yves.david@logilab.fr</a>> wrote:<br>> > ><br>> > > # HG changeset patch<br>> > > # User Pierre-Yves David <<a href="mailto:pierre-yves.david@logilab.fr">pierre-yves.david@logilab.fr</a>><br>
> > > # Date 1348160567 -7200<br>> > > # Node ID 99ab3ca5b10c516485db9be9b8f5f6764ea7c7f7<br>> > > # Parent 0f55ba7803997843a1e047f9b2fc112e53cabfb3<br>> > > clfilter: introduce `filteredrevs` attribute on changelog<br>
> ><br>> > You've taken a slightly different approach on how to implement<br>> > this thing than I have here:<br>> > <a href="http://mercurial.markmail.org/thread/2fv3e2lgqohxle2g">http://mercurial.markmail.org/thread/2fv3e2lgqohxle2g</a><br>
> ><br>> > What I liked about the wrapper classes is that it separates the logic<br>> > of the filtering from the base implementations of revlog/changelog.<br>> > As a result that means that if there aren't any filtered revisions then<br>
> > everything is the same as before (although the call 'x in set' where set<br>> > is empty is probably negligible).<br>> ><br>> > Any reason you think this is preferable?<br>><br>> Complexity.<br>
><br>> Most of the revlog methods can't be efficiently filtered afterward. This<br>> means that most complexe methods need to be reimplemented with filtering in<br>> mind causing a massive duplication of codes. However with minor changes to<br>
> the revlog code all those function can returns a properly filtered result if<br>> a few key lower level methods are overridden (mostly iteration). That's the<br>> meaning of all changesets that comes before this one.<div>
<br></div><div>I haven't seen this happening when I was working on it,</div><div>but I trust you've been working on it long enough to think so.</div><div><br>><br>> This approach allows minimal code duplication and low complexity. But it<br>
> requires to be implemented on changelog to redefines methods used in revlog<br>> code.<div>></div><div>><br>> > Are you sure these errors you're raising below are correct? It seems<br>> > to me that you shouldn't filter out revisions when they're asked for<br>
> > explicitly, but rather when one requests to know what is the set of<br>> > all revisions in the repository.<br>> ><br>> > For instance, if the user types `hg log -r 0` and 0 happens to be<br>> > filtered,<br>
> > I think we should still display it rather than saying the revision<br>> > doesn't<br>> > exist.<br>><br>> Yes they are. For multiple reasons:<br>><br>> (1) The `hg log -r 0` case is tricky. Hidden revision must be filtered out<br>
> of every commands by default (for consistency).<br>><br>> This means filtered for revset too. You can't have "hg bundle -r<br>> '42::' bundles more revision than `hg log -r 42::` do.</div>
<div><br></div><div>What's the difference here?</div><div><br>><br>> Then we have `hg log -r 0:0` that match nothing. Should `hg log -r 0`<br>> do ? I do not know.<br>><br>> The current approach is to<br>
><br>> A) Have global --hidden flags:<br>><br>> `hg log -r 0` --> no such revision<br>> `hg log -r 0 --hidden` --> Display 0<br>><br>> B) Have a dedicated sub class on Exception to detect it's filtered<br>
><br>> `hg log -r 0` --> Revision 0 is hidden. do you want --hidden ?<br>> `hg log -r 0 --hidden` --> Display 0</div><div><br></div><div>So --hidden is needed on any command that accepts a</div>
<div>revision? Ouch.</div><div><br>><br>> C) (maybe) make several command smarter<br>><br>> `hg log -r 0` --> Display 0 because 0 is explicit enough<br>><br>> This is far from perfect but it is the best I can come up with to get<br>
> a consistent experience for user. Any suggestion are welcome.</div><div><br></div><div>The way I saw it is that if a filtered revision is requested indirectly,</div><div>e.g. getting all revisions in a repo, getting children/descendants of</div>
<div>a revision, getting the heads, etc. then those results shouldn't contain</div><div>filtered revisions.</div><div><br></div><div>But when a revision is requested explicitly in some way then it</div><div>should be returned even if it's filtered, under the assumption that</div>
<div>if something (or one) is asking for it, it knows it's filtered (because it's</div><div>hidden normally and he had to look for it specifically to find it in</div><div>the first place) and he wants it anyway.</div>
</div></div>