Michael W Thelen wrote:
>* kfogel@collab.net <kfogel@collab.net> [2004-07-05 18:40]:
>
>
>>I guess this whole bit might change now, with the suggestion of
>>"-rHEAD:HEAD-10" syntax that others have made. (So I won't comment on
>>any of the parsing code.)
>>
>>As far as backwards compatibilty: When the server is new enough to
>>understand the new type of request, there should be no extra round
>>trip. When the server is old, it can error back to the client, which
>>the client can detect, and only *then* do an extra round-trip to
>>get the offset revision by number so it can re-request.
>>
>>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 think this would allow all the most popular uses for this change, e.g.:
* svn log -rBASE+1:HEAD targets...
Show commits since the working copy was last updated. It doesn't
matter whether or not any of the targets were actually changed in
the BASE+1 revision.
* svn diff -rCOMMITTED-1 targets...
Show the diffs from the last commit
* svn log -rHEAD-10:HEAD targets...
Show logs for the last 10 revisions, regardless of actual changes
in the targets
* svn diff -rHEAD:-3 targets...
Show the diff of the last 3 changes in any of the targets
Note that, for BASE, COMMITTED, etc., just like for :+3, each target
still has to be handled separately. In the first case, the
interpretation of the label itself depends on the target. In the second,
the actual revisions when the changes occurred do.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 6 09:38:03 2004