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

[Daniel Carosone]

On Tue, Feb 24, 2009 at 09:57:22AM -0700, Derek Scherger wrote:
> On Mon, Feb 23, 2009 at 10:03 PM, Daniel Carosone <address@hidden> wrote:
>
> 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:

Huh. Cool, but it highlights the deficiencies in my loosely-worded
summary of the options :) 

> $ mtn log --revision b:
> 
> which also allows multiple --revision selectors so different sets of revs
> can be included. 

Nice, and the obvious same name as elsewhere, now that i see it.  How
was this ever missing before now? :)

> 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?

Yeah, there is, if we elaborate on the real interpretation of the
three; see below.

> 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.

Some form of m:name-glob=value-glob or m:name=value-glob.  Or regex?
Jamming either glob or regex syntax into selector syntax could get
ugly, which is probably why c: punted on it.

> > 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.

You are, or rather I was: I omitted to explicitly state that the
--from and --to are inclusive, that is that they first select the
directly matching revisions, and then do the appropriate thing with
their descendants (either adding them also, or trimming them).

> > > 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?

previous-revision, and update could just rename revision to that,
before writing out the new _MTN/revision.

Not sure about the option, because this starts to get into the realm
of a workspace undo (e.g. also storing a _MTN/diffs/hash1-hash2 or
similar for each of the content changes in _MTN/revision)

> 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. ;)

Peel me a grape!  (Oh, and because I'm benevolent, you may peel one
for yourself also).

--
Dan.

pgp5CvU_TdhOD.pgp
Description: PGP signature