Ryan Kersh wrote:
> I did some black-box testing, and AFAICT, the only commands that accept
> ARG1:ARG2 revision arguments are blame, diff, log, and merge. Of those,
> only log has a non 0:HEAD default. The merge command requires the -r
> option and has no default.
Thank you for investigating. Those are indeed the only commands that take a
range. However, the present defaults (when "-r" is not given at all) are more
varied than you imply:
blame
1:BASE for a local target
1:HEAD for a URL (close enough to 0:HEAD for this argument)
diff
BASE:WC for a local target
(start is required; end defaults to HEAD) for a URL
log
BASE:0 for a local target
HEAD:0 for a URL
merge
(required)
Therefore the commands for which revision-range defaults of 0:HEAD would work
well are "blame" on a URL and "diff" on a URL. For the other commands and
targets, it would be confusing or inappropriate.
> It just seems natural to me that if the revision range ends become
> optional that we would use 0:HEAD, ascending from left to right, as the
> default. If "svn log" defaults to BASE:1 and "svn log -r:" is 0:HEAD, I
> think it would be okay, because the user would have to be pretty
> sophisticated to use the -r option in the first place, and would know
> what they were doing. I can see where you're coming from, but for me
> the handiness of it outweighs the possible surprises it might cause. You
> are probably a better judge of this... do you still think the 0:HEAD
> default is bad?
The way this feature is presently described in issue 2100 and implemented in
your patch is not right.
To do this properly, "svn" would need a way of distinguishing between "-r X"
and "-r X:" so that the former could be treated as a single revision, and the
latter as a revision range with an unspecified end, whose end is to be
determined by the specific subcommand, not by the generic argument parser.
I am still not sure that the ability to omit range ends is useful enough to
justify its existence, but if you would like to implement it in such a way that
the individual subcommands can interpret it as they see fit, I would reconsider it.
I'm sorry that the issue you chose to work on turns out to be undesigned and
mostly unreviewed. (The person who filed the issue appears never to have
contacted the mailing lists, which is against our policy.) Please feel free to
pick a different one unless you are particularly keen on this one.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 31 13:36:49 2005