Concept of the day: filesets?

Nicolas Dumazet nicdumz at gmail.com
Wed Nov 17 17:59:47 CST 2010


2010/11/18 Matt Mackall <mpm at selenic.com>:
> That'll work right up until I change the predicate to "not modified()"
> or make it "or contains('mpm')", etc. Yes, you can be extra clever and
> work around such bumps, but it's not hard to see that this quickly gets
> into experts-only territory.

Fair enough.

>
> I'm surprised you can't look over at revsets and think "wow, that really
> is amazingly powerful and useful, and doing that sort of thing with
> files would probably also be quite useful." Yes, I could in fact do just
> about everything revsets does with a hairy pipeline of log -q and uniq
> commands, but it wouldn't exactly be convenient.

Actually, from time to time I feel uncomfortable with revsets too.
Yes, it's super powerful and helpful.
But then, for instance, most of the options from log are not useful
anymore, or could be replaced by a revset. log -b foo is log
-r"branch(foo)"
 and so on. And if we add "modified()" filters the same goes on for hg st -m

Of course log -b is shorter, and I use this instead of a revset. And
on the other hand, revsets are more expressive. So yes, I do want
fileset and revsets.
But I still think it's important to keep in mind that we have a small
duplication here.
For instance, hg log -r REV FILE was broken in 1.7, but not log -r"REV
and file(FILE)". We have different code paths, that probably have
different performances. Such bugs, or performance gaps will happen
more and more.

Am I being the grumpy, skeptical one? Oh, maybe, and I'm sorry about that.
But sure, let's go forward, let's get these filesets and see what
users make with them.

>
>> In reality, I feel that it would take us away from the "There should
>> be one-- and preferably only one --obvious way to do it."
>
> xargs is the obvious way to maybe 5% of users.
>

Depends. SVN teaches you xargs ;)
(And yes, that's actually becoming an argument in favor of filesets for hg.)


-- 
Nicolas Dumazet — NicDumZ


More information about the Mercurial-devel mailing list