On Mon, Feb 23, 2009 at 09:22:21PM -0700, Derek Scherger wrote:
> On Mon, Feb 23, 2009 at 12:17 PM, Daniel Carosone <
address@hidden> wrote:
>
> > If only there was some more generic and existing syntax that allowed
> > us to select interesting revisions...
>
> ... that was used by log to specify the set of revisions to be listed.
Heh, well, yeah :)
I did have a quick look at log last night to
see what it might take to make this happen and it's pretty simple. The
--from and --to options allow selectors already, which isn't
surprising, and I "discovered" one way of logging revs from a single
branch is:
$ mtn log --from b: --to b:
It's a bit of a
shame that you need to specify the same selector twice but this is
already better than the pipelined automate equivalent. I've made a
small local change to add support for --revision/-r to log which allows
for:
$ mtn log --revision b:
which also allows multiple --revision selectors so different sets of
revs can be included. At the moment I have this set to fail if
--revision is specified with --from or --to but maybe there's a good
way for these to interact? This is a simple change and unless there are
any objections I'll probably clean it up and commit it to mainline,
with tests, a NEWS entry and documentation of course!
One nice consequence of using --revision is that there is a definition
of "done" so that log can stop when it has logged all of the specified
revs.
I'd like to add an m:glob selector that is applied against changelog
and comment certs too. I see there is a c:foo=bar selector that does
something similar but it looks for exact matches and I think it would
be more useful to be able to match patterns in the message certs.
> Maybe that's the real problem though and I should go see what I can do about
> teaching log to work with selectors. Off hand I'm not sure how these would
> play with --from and --to?. Maybe not at all and you either specify
> --from/--to or some selectors?
I dunno.. ISTM that they all are ways of adjusting the result set.
--select: add the matching revs
--from: add descendants of the matching revs
--from
already takes a selector so you would need use the same selector as in
the fictitious --select which doesn't accomplish anything new.
--to: prune descendants of the matching revs.
ditto, unless I'm missing something here.
> "those on this branch two days ago". It would also be nice to be able to say
> "log --updated" and have that list all revisions that the last update
> brought into the current workspace. Update would have to cooperate for this
> to work, by recording the base rev id before it changes things.
Nice idea, some kind of workspace history of previous state(s)..
We could use an option for this (--updated or
--recent) or yet another selector (u: or r:) although it may make more sense as an option, since it wouldn't be going through the normal database selector lookups. Update will have to record the parent rev in _MTN/somewhere before moving so that the new option/selector can get it. Then this is nothing more than log --from that-rev --to this-rev.
Any preferences on option or selector, or what they should be called, or what to call _MTN/somewhere?