In darcs 2.0.2 and also built from the current darcs repo, "darcs changes
--context --tags=xxx" and "darcs changes --context --to-tag=xxx" don't give
useful output for "non-recent" tags, that is, those that don't appear in the
output of "darcs changes --context | grep TAG".  With a recent tag, such as
2.0.2 in darcs's own repository, they produce the expected

    Context:

    [TAG 2.0.2
    David Roundy <droundy@darcs.net>**20080624012041]

however with 2.0.1 I get

    Context:

for --tags and

    Context:

    darcs: Couldn't find a tag matching "tag-name 2.0.1"

for --to-tag

droundy says that --to-tag should definitely work.  I'm not sure whether or not
he meant that --tags should work too, so I'm mentioning it just in case.  This
may also apply to some of the other "darcs changes" options for selecting
patches, but I'm only interested in --tags and/or --to-tag ;-)

So, our diagnosis on #darcs [1] was that changes --context only looks up to the
last checkpoint tag (i.e. --tags, --from-tag will work, but often, there aren't
any non-checkpoint tags since the last checkpoint, and users like dleverton see
no results).

We can reproduce it, and we have a rough idea what is going on.

The only things which are unclear are what to do about it:
- should changes --context match all patches? that doesn't sound very reasonable
- should changes --context match up to the last checkpoint, except when there
are other flags, in which case it matches all tags and does filtering accordingly?
- is it even reasonable for --context to  filter patches? I suppose the --from
and --to matcher (both on tags and patches), as well as --index make some sense

Thoughts?

[1] http://irclog.perlgeek.de/darcs/2008-09-01

FWIW, my intention here is to get the equivalent of
    darcs get --tag=xxx /my/repo /my/scratch/repo
    darcs changes --context --repodir=/my/scratch/repo
but without having to create an extra copy of the repository.  I personally only
care about --tag, but it might make sense for --to-match and --to-patch as well.

On Tue, Sep 2, 2008 at 3:21 PM, David Leverton <bugs@darcs.net> wrote:
> droundy says that --to-tag should definitely work.  I'm not sure whether or not
> he meant that --tags should work too, so I'm mentioning it just in case.  This
> may also apply to some of the other "darcs changes" options for selecting
> patches, but I'm only interested in --tags and/or --to-tag ;-)

I don't think --tags should be compatible with --context, simply
because --context only makes sense when outputting a complete history,
and --tags doesn't respect dependencies (as e.g. --patches would also
make very little sense with --context).

David

Some clarifications here: 

1. I think I was wrong when I said this had anything to do with checkpoint tags.
 More that it was tags that were deemed safe to move into a separate inventory
(optimize among other things)

2. David Roundy is right that the --tags matcher in particular should not work
with --context.  Nothing that ignores dependencies should work with --context. 
I've opened a new ticket for this in issue1534

3. David Leverton doesn't want to break dependencies, just to grab changes
beyond the inventory cut-off point, which sounds fair enough.

I would say that under changes --context, maybe the --tag matchers need to work
a little harder?

Note that this bug is mutually exclusive with issue1534.
It'd be a good idea to refer to msg1579 from issue428.

The problem is that changes --context is ill-defined with matchers like -p and
--last.  One solution (issue1534) would be to refuse to accept matchers.

Another solution would be to define a clear meaning for changes --context -p
(etc) and then implement it.

I'll leave this need-action for somebody to work out a proposal.

(One proposal: the matchers mean 'give me a context which includes at least
these patches')

[I just merged in the one message from issue1597]

After last looking at this, I think I have a slightly better
understanding of the situation.  

Basically, darcs changes uses matchers without caring about
dependencies.  This is useful because dependencies are meaningless in
the context of searching the changelog (eg. --match 'author Eric').  

On the other hand, dependencies are very much meaningful for the task of
producing a context file.  It seems somewhat awkward to have this sort
of mysterious flip-flopping in matcher semantics depending on whether or
not you pass in the --context flag.

There are three solutions to this bug:

1. here and duplicate issue1597: make matchers behave the right way in
darcs changes --context
2. issue1534: refuse matchers for darcs changes --context
3. issue1258: introduce a new command darcs show context with matchers
that have the right way

Solutions #1 and #2 are mutually exclusive.  And so are solutions #1 and
#3, it would seem.  Solutions #2 and #3 could be quite complementary. 
My personal preferences are for the latter two.  I'm going to wont-fix
this tentatively...