Justin Erenkrantz wrote:
> On 3/13/06, Julian Foad <julianfoad@btopenworld.com> wrote:
>
>>We've got a nasty relic of a meaning of "-r" in "diff --old --new" syntax.
>
>
> I think independently I ran into what you mean. The -r syntax doesn't
> do anything close to what it should do.
>
>
>>The peg-rev notation was added in r9707, round about v1.1, changing the help to:
>>
>> 2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
>> [PATH...]
>>
>>That is when "-r" was made to provide "defaults" for the peg revs, in order to
>>maintain compatibility with the v1.0 UI syntax.
>
> Per my other email, that's not true. Setting '-r' doesn't do anything
> for peg revs. (Perhaps it should?)
By "the peg revs" I meant the revisions specified as "@OLDREV" and "@NEWREV".
(Is that what you understood?) The "-r" does indeed provide default values for
OLDREV and NEWREV in my tests. In this test, "f" was renamed to "g" in r1353,
and HEAD is r1358:
$ svn diff --old=$HERE_URL/f --new=$HERE_URL/f
svn: '[...]/f' was not found in the repository at revision 1358
$ svn diff -r1350:1352 --old=$HERE_URL/f --new=$HERE_URL/f
Index: f
===================================================================
[...]
>> * error or warn if both "-r" and an "@" are specified, because that was
>>never intended
>
> That's currently mandatory if a path has been deleted.
With the diff invocation syntax type (1), both "-r" and "@" are required for
comparing two revisions of a deleted item.
It appears that you are confusing that with this "--old/--new" diff invocation
syntax (2) in which "-r" does not specify operative revisions.
>> * deprecate "-r" by changing the help to say so
>>
>>but those would both be incompatible UI changes. Would either of them be
>>desirable on balance?
>
> I think -r is the logical usage - not URL@REV. It fits with up, log,
> blame, etc.
Logical usage for doing what? It's not simply a question of having one or the
other, it's a question of what each one means.
If we support "--old=URL@REV", as with other commands it should mean that REV
is the "peg" revision, i.e. a revision in which the specified URL exists and
the revision in which it should first be found. It already is supported and
does mean that, so there's no problem.
If we support "-r N[:M] --old...", as with other commands it should mean
"operate on revisions N and M, or the revision range from N to M, of the
object", but this is neither what it currently means nor a good fit for the
syntax which specified TWO separate objects (--old and --new), so that's why I
say we should (eventually) drop the "-r" option from this syntax altogether.
>>In short, I'm trying to find a migration path from having this horrible meaning
>>of "-r" to eventually either not having "-r" or having it specify operative
>>revisions as it does in other commands and particularly in other forms of "svn
>>diff".
>>
>>Does anyone see any better steps along that road?
>
> I'd go back to our 1.0 UI and drop peg revs entirely. *duck* -- justin
Heh.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 19:20:19 2006