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

Josh Pieper <jjp@pobox.com> writes:

> > This defaulting would be consistent with what you've done with commands
> > like cat in your patch.
>
> Does anyone have objections to this change? Namely defaulting the
> ending rev of a diff to the peg revision if no end revision is
> present? I think it makes sense, so I'll go ahead and make it if no
> one objects.

   "In Subversion, our subcommand targets are either local paths or remote
    URLs. Because objects can be renamed throughout time, we use the
    concept of a 'peg revision' to ...

    All subcommands which operate on specific revisions of objects
    accept the 'peg revision' syntax, which looks like ...

    Of course, there are exceptions to this. ..."

GACK! Exceptions! Why in Heaven's name must there always be
exceptions?!

I'm not quite -1 (reeeeeeeeally close), but I canNOT stress enough the
importance of consistency across the UI of a command-line tool. Let
the GUIs choose different defaults for different subcommands, because
they *show those defaults* via UI widgets *every time* someone
performs that action.

Please. URL peg revisions default to HEAD. Working copy path peg
revisions default to WORKING. Period. You've even got code to figure
this out for you when you pass in "unspecified" peg revisions. Yes,
this may cause folks to have to think a little bit if their URL has
been renamed or removed from HEAD -- but the inconsistency is a higher
price to pay in my opinion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 2 16:19:44 2004