You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Josh Pieper <jj...@pobox.com> on 2004/11/02 13:12:02 UTC
Re: Should all sub-commands accept a peg-revision?
Greg Hudson wrote:
> 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.
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.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 10:17, C. Michael Pilato wrote:
> 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.
I was proposing a change which would bring greater consistency, not
less. Can you be more specific in your objection? I'll be more
specific in my argument:
Assumption: "svn cat target@PEG" should be equivalent to "svn cat -r PEG
target@PEG". (This is already true.)
Conclusion: Therefore, "svn diff -rN target@PEG" should be equivalent to
"svn diff -rN:PEG target@PEG". (This is not already true; the upper
operative revision defaults to HEAD instead of PEG.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Josh Pieper <jj...@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
Re: Should all sub-commands accept a peg-revision?
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Tue, 2004-11-02 at 12:43, Julian Foad wrote:
>
>>Is this part of your proposal:
>>
>> PEG defaults to the current working version if any TARGET is a working copy
>>path, otherwise it defaults to HEAD.
Oops - I copied and pasted the second half of that sentence from the
description of ":M" in "svn help diff", without thinking about its new meaning.
> I believe PEG is separate for each target, so that's an odd way of
> putting it.
>
>> M defaults to PEG.
>
> ... which means M could vary per target. But I think that's fine; each
> target is a completely separate diff operation.
Huh. I wasn't making a proposal, I was trying to get you to clarify what your
proposal was.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 12:43, Julian Foad wrote:
> Is this part of your proposal:
>
> PEG defaults to the current working version if any TARGET is a working copy
> path, otherwise it defaults to HEAD.
I believe PEG is separate for each target, so that's an odd way of
putting it.
> M defaults to PEG.
... which means M could vary per target. But I think that's fine; each
target is a completely separate diff operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by kf...@collab.net.
Julian Foad <ju...@btopenworld.com> writes:
> > The rule you state should be taken with a grain of salt. There's no
>
> That's OK by me if others agree.
I agree with Greg. In order to fix legitimate useability bugs, we may
have to subtly change the meaning of certain syntaxes. Of course, we
have to use our judgement about when to do so (and we are).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Tue, 2004-11-02 at 08:50, Julian Foad wrote:
>>Objection: I don't think you can change the meaning of existing commands before
>>version 2.
>
> You mean, like we changed the meaning of "svn diff -rN filename" in svn
> 1.1 when we added history-tracking?
>
> The rule you state should be taken with a grain of salt. There's no
That's OK by me if others agree.
In that case, please could you state the proposal a bit more completely, say as
a patch to "svn help diff" and "svn help merge"?
The current help for "diff" isn't complete:
> diff (di): Display the differences between two paths.
> usage: 1. diff [-r N[:M]] [TARGET[@REV]...]
> 2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
> [PATH...]
> 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
>
> 1. Display the changes made to TARGETs as they are seen in REV between
> two revisions. TARGETs may be working copy paths or URLs.
>
> N defaults to BASE if any TARGET is a working copy path, otherwise it
> must be specified. M defaults to the current working version if any
> TARGET is a working copy path, otherwise it defaults to HEAD.
This doesn't say what PEG defaults to.
Is this part of your proposal:
PEG defaults to the current working version if any TARGET is a working copy
path, otherwise it defaults to HEAD.
M defaults to PEG.
?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 08:50, Julian Foad wrote:
> Objection: I don't think you can change the meaning of existing commands before
> version 2.
You mean, like we changed the meaning of "svn diff -rN filename" in svn
1.1 when we added history-tracking?
The rule you state should be taken with a grain of salt. There's no
excuse for changing an API function's signature so that every program
which uses the function suddenly fails to compile, but there are plenty
of good reasons to change the semantics of a particular call to be
better. Same for a command-line syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should all sub-commands accept a peg-revision?
Posted by Julian Foad <ju...@btopenworld.com>.
Josh Pieper wrote:
> 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.
You mean to do this for "merge" as well as "diff", don't you? It would be
confusing to make them different from one another.
Objection: I don't think you can change the meaning of existing commands before
version 2.
(When you add support for "@REV" to commands that didn't support it before, you
can have it mean whatever you like.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org