[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:17:07 CET

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

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

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.