[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Should all sub-commands accept a peg-revision?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-11-02 16:57:37 CET

Julian Foad <julianfoad@btopenworld.com> writes:

> > 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.
>
> Not necessarily. 'svn cat -r x URL' doesn't have to mean 'URL@HEAD'.
> We could make it mean 'URL@x'. This would be backward-compatible. If
> fact, you could argue that such compatibility is essential, even if it
> isn't the "nicest" meaning.

Or you could argue that we've had a bug all this time that prevented
folks from seeing the thing they were supposed to be seeing, and we've
finally fixed it.

> propget/list but not propset/edit/del? That sounds like a recipe for
> confusion. Is there a technical reason for this or have you just not
> done the others yet?

Don't get me started on recipes for confusion, Mr. "-rX doesn't have
to mean URL@HEAD; it could mean URL@X". :-)

Okay, so, actually, I could probably be convinced that if there was a
rule *across ALL subcommands* whereby a -r[X:]Y was present, and there
was not an explicit peg revision noted, that the default peg revision
changes to Y instead of HEAD or WORKING. That kind of one-line
exception that is universal in its application is soooooooooo much
more acceptable to me than per-subcommand exceptions.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 2 17:00:33 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.