monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] log options and staying on the current branch


From: Derek Scherger
Subject: Re: [Monotone-devel] log options and staying on the current branch
Date: Tue, 24 Feb 2009 09:57:22 -0700

On Mon, Feb 23, 2009 at 10:03 PM, Daniel Carosone <address@hidden> wrote:
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?
 
- I'd probably object less to this output format as a default, than to
the only-on-branch format, if indeed a default was to be changed at
all, and if indeed my opinion mattered at all.

Yeah, the reason I'm discussing it is because it did mean a default change. Unfortunately we seem to be in a bit of a design-by-committee state these days, maybe we should put out an add for a benevolent dictator. ;)

Cheers,
Derek


reply via email to

[Prev in Thread] Current Thread [Next in Thread]