[PATCH] fileset: evaluate status sets in working directory (BC)

[Martin von Zweigbergk]

On Fri, Mar 20, 2015 at 9:38 PM Yuya Nishihara <yuya at tcha.org> wrote:

> On Sat, 21 Mar 2015 03:39:28 +0000, Martin von Zweigbergk wrote:
> > On Fri, Mar 20, 2015 at 8:10 PM Yuya Nishihara <yuya at tcha.org> wrote:
> > > Another use of the current behavior is to archive changed files at that
> > > revision.
> > >
> > >   $ hg archive -r $rev -I 'set:added() or set:modified()'
> > >
> >
> > That's a fair example that I don't have an answer for (before we make it
> > possible to pass a different context to the fileset). What do you use it
> > for?
>
> TortoiseHg has a checkbox to archive "only files modified/created in this
> revision". I know this checkbox is actually used because there were several
> bug reports about it.
>
> > > > Since it seems like the user should mostly want to have status
> > > > filesets evaluated against the working directory, and since that's
> > > > also what the documentation seems to suggests, let's make it so.
> > >
> > > IMHO, "revert" is the only exception that I expect fileset is evaluated
> > > against workingctx.
> > >
> > > > we can later add a revision argument to these filesets ("hg files -r
> $rev
> > > > 'set:modified($rev')") if we see a need.
> > >
> > > I don't think 'set:modified($rev)' would work well because a fileset
> > > function
> > > narrows down given subset, which might not include all files at $rev.
> >
> > I guess I don't know enough about filesets to follow. What's the "given
> > subset" here? Could you give an example of how to produce such a subset
> > that doesn't include the files?
>
> I meant mctx.subset. The initial mctx.subset should be calculated from the
> provided ctx, but repo[$rev] can have files that does not exist in the
> initial
> mctx.subset.
>
> I think I can explain the problem better if I send patches that implements
> "set:wdir(modified())" function.
>
> Regards,
>

Sounds good. Now that I realize that I have to bite the bullet and touch
largefiles anyway, I don't depend on this patch getting in. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150321/1b1a4a32/attachment.html>