Just to raise another little issue, I think
svn diff -r N TARGET@PEG
should default the upper operative revision to PEG. Right now we
default it without regards to the peg revision, so a command like:
svn diff -r 7303 http://svn.collab.net/repos/svn/trunk/subversion/libsvn_fs/id.c@7304
fails because it it tries to do a forward-lookup of
subversion/libsvn_fs/id.c from peg-rev 7304 to head.
This defaulting would be consistent with what you've done with commands
like cat in your patch.
On Sat, 2004-10-23 at 06:32, Josh Pieper wrote:
> 1. Is this desirable in the first place? Adding tracing by default to
> sub-commands makes the most intuitive way to specify a specific
> revision, 'svn cat -r x URL', perform history tracing from HEAD.
> This could possibly take a long time, especially with the new authz
> security fixes. You would need to use 'svn cat URL@r' to get the
> same quick response as before.
I think it's desirable. Tracing doesn't generally take more than a few
seconds.
> 2. There are other sub-commands that reference specific revisions of a
> file/directory but don't currently perform any tracing. (copy,
> export, checkout). Should they be modified to use the new syntax
> and semantics?
Ideally, yes. Users should be able to rely on consistent meanings of
url@N and -r N url.
> 3. How do we describe this in help messages? My attached patch punts
> on that question, and just shows the extra possible field. In my
> attempts to describe peg revisions in the docstrings of the
> libsvn_client functions, I was unable to find a simple wording that
> would be easily understandable in the limited space of a help message.
Maybe this is too subtle for the help output. We already seem to punt
on describing the peg-rev in the case of diff. But I can suggest
wording like:
Usage: svn cat [-r N] TARGET[@REV]
Displays the contents of TARGET as of revision N. If specified,
REV controls where the target is looked up. If N is not
specified, it defaults to REV if given, or to HEAD for URLs or the
current working copy version for working copy paths.
... which raises another little side issue: right now "svn cat wcpath"
seems to display the base text of wcpath, not the current text. This is
inconsistent with our other commands. (Yeah, I know, it's anybody's
guess why you'd want to use "svn cat" instead of just "cat" or "type"
for that, but that's no excuse for second-guessing.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 23 18:18:44 2004