obtains logs of revisions from the date?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthieu Moy wrote:
> One point, though: I was thinking of adding a variant to the X..Y
> notation, allowing multiple -r options (I think that's the way CVS
> does).

I'm +0 on this.  When multiple options are supplied, the effect is
usually that the the new value overrides the previous.  It will change
the effects of aliases, too.  Right now, I have 'bzr log' aliased to
'log --short -r -1..-10'.  If I supply an explicit -r-1, that changes
the effect to 'bzr log --short -r-1'.  With your proposed syntax, it
becomes 'bzr log -r -1..-10..-1', which produces "bzr: ERROR: bzr log
- --revision takes one or two values."

I think making options additive makes it hard to override them,
generally, and also makes them a bit surprising.  OTOH, it will make the
transition easier for CVS users, so it does have some advantages.

>   $ bzr diff -r 1..3
> 
> is very nice, but
> 
>   $ bzr diff -r branch:/path/to/branch/..date:yesterday

This means
"show me the difference between the last-revision in path/to/branch and
the first thing I committed to the current directory yesterday".  Is
that what you intend?

>   $ bzr diff -r branch:/path/to/branch \
>              -r date:yesterday

I think a lot of this can be fixed by just fixing branch so that we can
diff remote branches easily.  In the common case, it's
"bzr diff path/to/branch .", though I usually find the ancestor makes a
better diff, because it means we don't get a negative patch for the
revisions that were made to the other branch since our last merge.

> And it becomes even worse if you allow arbitrary remote revision (see
> my proposed patch for revno:N:branch, or the other discussed syntax
> with /path/to/branch,revno=N). Not even talking about branches with
> relative path which themselves contain ".."!

It seems to me that we really need a commandline parser that produces
(branch_or_tree_path, revision_spec, file_list) tuples, and then having
commands interpret *that* according to their needs.

> In this case, it makes argument parsing more complex, because when you
> parse "date:some_date", you don't yet know whether there is another -r
> argument on the command line, so you don't know whether to use the
> range or a single point in time.

Worse still, there is no limit to the number of revisions that may be
passed on the commandline, though the maximum any command supports is two.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEexcm0F+nu1YWqI0RAvi9AJ9YVl6vV4anYK3pK85UkXRon0NWWACgiKnG
MKimybCZA/VD5WDJY/Fju8c=
=lRYo
-----END PGP SIGNATURE-----