obtains logs of revisions from the date?

[Jan Hudec]

On Mon, May 29, 2006 at 14:37:32 +0200, Matthieu Moy wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
> 
> > I think it would make sense if revision specs could produce ranges as
> > well as single revisions.  Then -r date:some_date could produce the
> > range from the start of the day to its end (though this is tricky, due
> > to time zones.).
> 
> Globally good idea.
> 
> 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 have checked Subversion and Mercurial. Subversion does *NOT* do it
that way (and so neither does SVK), while Mercurial does it. So yes, CVS
users will be used to it, but it's not that strong precedent now.

Oh, I can also mention GNU Arch, which did not have -r option at all,
but used revision names, which roughly corresponds to the other
(URL-parameters) syntax.

>   $ bzr diff -r 1..3
> 
> is very nice, but
> 
>   $ bzr diff -r branch:/path/to/branch/..date:yesterday
> 
> starts to be unreadable, and I'd prefer
> 
>   $ bzr diff -r branch:/path/to/branch \
>              -r date:yesterday
> 
> 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 ".."!

With the other discussed syntax, there is *NO -r* in the first place. In
that syntax your above example would be:

  $ bzr diff /path/to/branch .,date=yesterday

(The ',' would be probably configurable, so people used to use it in
filenames could choose something else for path arguments--'?' or '@@' or
whatever.)

> 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.
> 
> That's probably manageable, but from the user point of view, I also
> find it a bit strange that in
> 
>   $ bzr diff -r date:yesterday [...]
> 
> the meaning of date:yesterday may depend on the content of "[...]".

It certainly should not do that.

> > Another range that most people would like would be one that allowed them
> > to see the changes introduced by a revision.  That is, "bzr diff -r
> > changes:5" would show you the changes introduced by revision 5, relative
> > to revision 4.
> 
> +1 !

Yes, this is indeed good idea.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060530/00f12ebf/attachment.pgp