Re: [PATCH] 'last N changes' mode for svn log

* Branko Čibej <brane@xbc.nu> [2004-07-06 01:36]:
> >>So, here's a wicked question: shouldn't an offset of "HEAD-10" on a
> >>file show you the last ten revisions *in which that file changed*, not
> >>simply the revisions numbered HEAD through HEAD-10? :-) (Or did your
> >>code already do that, and I just missed it?)
> >
> >If the repos HEAD revision is 100, I would expect HEAD:HEAD-10 to return
> >the log messages for the range 100 through 90, regardless of how many
> >changes were undergone by the target(s) in that range. I see "HEAD-10"
> >as specifying a revision number independent of any targets.
> >
> >That's not to say that "give me the last 10 log messages" isn't a very
> >common desire. I'm just not sure HEAD:HEAD-10 is the syntax for it.
> >Something more like HEAD:HEAD-10C (last ten changes before HEAD), or a
> >different command-line option entirely, like --limit 10, would make more
> >sense to me.
> >
> Since there's a case for both interpretations, I suggest making the
> change slightly differently. I think the "N changes" interpretation only
> makes sense if you have already have a fixed reference revision to count
> the changes from. So I suggest the following (where FIX is any kind of
> absolute revision reference, either number, LABEL or {date}):
>
> * -rFIX([+-][0-9]+)?
> Specifies a particular revision. If the offset is present, the
> calculated revision number is modified by the offset, regardless
> of how many changes the targets have experienced since then.
> Otherwise, current behaviour doesn't change
> * -rFIX([+-][0-9]+)?:FIX([+-][0-9]+)?
> Specifies a revision range, again using absolute revision numbers
> instead of change counts.
> * -rFIX([+-][0-9]+)?:[+-][0-9]+
> This is the special case. The first argument specifies an absolute
> revision number; the second one counts the number of changes
> forward or backward from that revision number.

I could go for that... so when a (possibly symbolic) revision number is
given with possible addition or subtraction, it always refers to a
specific revision number. That's what I would expect. Of course, cases
like -rCOMMITTED-1 are still a little weird with multiple targets, since
they evaluate to absolute revision numbers, but differently for each
target.

Actually, the more I think about it, the more I like the --limit idea.
This could also take care of the common cases, but in a more intuitive
way (to me). In probably the most common case ("show me the last 10 log
messages"), its use is immediately clear:

svn log --limit 10 <target>

And in any other case, you can still specify a revision range and then
use --limit to limit the output:

svn log -r50:HEAD-10 --limit 5 <targets>
(if HEAD is 100, show me at most 5 log messages for changes to any of
the targets between r50 and r90)

Hmm, but the weirdness persists with symbolic revisions like BASE,
COMMITTED, and PREV evaluated differently for each target. Then again,
if we use these to refer to absolute revision numbers (and we currently
do), I think that weirdness will always be there.

What do you think? Are there cases that are not able to be handled by
one approach or the other? I find the --limit approach more
understandable, but that may just be me.

-- Mike

-- 
Michael W. Thelen
The easiest person to deceive is one's self.
                -- Edward Bulwer-Lytton, "The Disowned"